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Abstract 


In this paper we consider the problem of translating core F#, a 
typed functional language including mutable variables and exception 
handling, into scripting languages such as JavaScript or Python. In 
previous work, we abstracted the most significant characteristics of 
scripting languages in an intermediate language (IL for short). IL 
is a block-structured imperative language in which a definition of a 
name does not have to statically precede its use. We define a big- 
step operational semantics for core F# and for IL and formalise the 
translation of F# expressions into IL. The main contribution of the 
paper is the proof of correctness of the given translation, which is done 
by showing that the evaluation of a well-typed F# program converges 
to a primitive value if and only if the evaluation of its translation into 
IL converges to the same value. 


Keywords: functional languages, scripting languages, correct transla- 
tion, intermediate language 


1 Introduction 


Programming in JavaScript (or any other dynamically typed language) opti- 
mizes the programming time, but can cause problems when big applications 
are created. The absence of type checking may cause unexpected application 
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behaviour followed by onerous debugging, and introduce serious difficul- 
ties in the maintenance of medium to large applications. For this reason 
dynamically typed languages are used mostly for prototyping and quick 
scripting. 

To deal with these problems, in previous work, [12] and [14], we proposed 
using dynamically typed languages as “assembly languages” to which we 
translate the source code from F# which is statically typed. In this way, we 
take advantage of the F# type checker and type inference system, as well 
as other F# constructs and paradigms such as pattern matching, classes, 
discriminated unions, namespaces, etc., and we may use the safe imperative 
features introduced via F# mutable variables. There are also the advantages of 
using an IDE such as Microsoft Visual Studio (code organization, debugging 
tools, IntelliSense, etc.). 


To provide translation to different target languages we introduced an 
intermediate language, IL for short. This is useful, for instance, when 
translating to languages that do not have complete support for functions 
as first class objects (such as some Python dialects) or for translating to 
JavaScript (optionally using libraries such as jQuery). 


In this paper we prove the correctness of the compilers produced. To 
do that we formalize the dynamic semantics of the languages F#and IL, the 
type-checking for F#, and give a formal definition of the translation from 
the source language F# to IL. We prove that the translation preserves the 
dynamic semantics of F# expressions. The language IL is imperative and 
untyped, and has some of the characteristics of the scripting languages that 
makes them flexible, but difficult to check, such as blocks in which definition 
and use of variables may be interleaved, and in which use of a variable may 
precede its definition. This is used to translate mutually recursive function 
definitions. (IL is partly inspired by IntegerPython, see [21].) Therefore, 
the proof of correctness of the translation from the source language F# to 
TL already covers most of the gap from functional to scripting languages. 


In order to facilitate the proof of correctness, instead of the small- 
step semantics we introduced in [12], we give a big-step semantics to both 
languages. Then we define an equivalence between values and an equivalence 
between runtime configurations and show that equivalent configurations 
produce equivalent values and also that divergence is preserved. Since big- 
step semantics does not distinguish between non-terminating computations 
and computations that “go wrong” we give a coinductive characterization 
of divergent computations, and show that well-typed F# expressions either 
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converge to a value or diverge. 

The paper is organized as follows: in Section 2, we formalize the fragment 
of F# which is our source language and state its main properties. In Section 
3, we introduce IL by first highlighting some of the design choices made for 
the language and then presenting its syntax and operational semantics. In 
Section 4, we briefly discuss the challenges of the translation, formalize the 
translation giving the translation of F# expressions to IL constructs, and 
we prove that an F# program converges to a primitive value if and only if 
its IL translation converges to the same value. In Section 5, we sketch the 
implementation of the compiler and some possible extensions. Section 6 
reviews the related work, and Section 7 draws some conclusions and discusses 
future work. The first two appendices contain the proof of the lemmas of 
type preservation and progress for F# expressions, stated in Section 2. These 
are the results from which the soundness of the type system for F# is proved. 
The third appendix contains the proof of the main lemma needed to prove 
the correctness of the translation. 


This paper is an extended and completely revised version of [12] and [14], 
whose aim was to introduce IL and show the challenges of the translation. 
In this paper, we give a different definition of the operational semantics of 
both languages, add exception handling to the source and target languages, 
and formalize and prove the correctness of the translation from the source 
language F# to the target language IL. Following the suggestion of a previous 
referee, we also define a translation which is simpler that the one of [12] and 
[14]. 


2 Core F# 


The syntax for core F# language is presented in Fig. 1. We include constructs, 
such as let, let mutable, let rec, raise and try-with that are used 
in the practice of programming and that raise challenges in the translation 
to dynamic languages. We do not introduce imperative features through 
reference types, but through mutable variables, as this is closer to the 
imperative style of programming. Reference types, with assignment and a 
dereferencing operator, could be easily handled. We present a simply typed 
version of F#. However, our translation does not depend on the presence of 
types, since it uses F# type inference. 

In the grammar for expressions, in Fig. 1, the square brackets “ [.. .]” 
delimit an optional part of the syntax, we use z, y, z for variable names, 
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e u= «£|n|tr|fls|F|e+e|if e then e else e|ee|e,e 

| let [mutable] z:T=e in e| let rec w:T=F ine|r<e 

| raise e|try e with rt > e expression 
Fon= fung:T>e function 
T := int|bool| ToT type 


Figure 1: Syntax of core F# 


and the overbar sequence notation is used according to [15]. For instance: 
“%:T=F” stands for “ 2:Tj=F, +--+ %:Tn=Fn”. The empty sequence is 
denoted by “ (@”. For an F# expression e the free variables of e, FV(e), 
are defined as usual. Note that, in the let rec construct, the occurrences 
of variables in W in F are bound. An expression e is closed if FV(e) = 9. 
We assume equality of expressions up to a-equivalence. With e[z := e’] 
we denote the result of substituting x with e' in e with renaming of bound 
variables if needed. 

The let rec construct introduces mutually recursive functions. The 
let construct (followed by an optional mutable modifier) binds the variable 
x to the value resulting from the evaluation of the expression on the right- 
hand-side of = in the evaluation of the body of the construct. In the syntax 


and “ in” are substituted by “carriage return” 


of the examples, as in F#, “,” 
without indentation. 

When the let construct is followed by mutable the variable introduced 
is mutable. Only mutable variables may be used on the left-hand-side of an 
assignment. This restriction is enforced by the type system of the language. 
The type system also enforces the restriction that the body of a function 
cannot contain free mutable variables, even though it may contain bound 
mutable variables. We did not model the fact that top level mutable variables 
could be used in functions, however our compiler handles such variables. 

The construct raise e raises an exception with the value of the ex- 
pression e. Exceptions are caught with the try e; with x — eg construct. 
In case the evaluation of e; raises an exception, in the evaluation of eg the 
variable x is bound to the value raised. 

We present a simply and fully typed version of F#. Function parameters 
as well as variables defined in the let, let mutable, and let rec constructs 
are annotated with their type. This is just to simplify the proof of the 
correctness of the translation. As already mentioned, our translator takes 
as input the standard polymorphically typed F#. We also assume that 
expressions associated with exceptions be of type Tr. 
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A type environment I is defined by: 
PtSi eae ho 


that is I associates variables with types, possibly followed by !. If the 
type is followed by ! this means that the variable was introduced with 
the mutable modifier. Let + denote either ! or the empty string, and let 
dom(T) = {x | «:Tt € T}. As usual we assume that IT is mapping on 
variables. We say that the expression e has type T in the environment IT 
if the judgment 

Tre: T 


is derivable from the rules of Fig. 2. In the rules of Fig. 2, with T[I'’] we 
denote the type environment such that dom/(I|I’]) = dom(T) U dom(I”) 
and: 


e if a:7t el’ then w:77 ETI"), and 
e if a:7t eT and x ¢ dom(I"), then z:77 ETI’). 


In the following we describe the most interesting rules. 

Consider rule (TyAss). To type the body of a function we need assumptions 
about its free variables and formal parameter. From the definition of T{I’] 
we have that, in the environment in which the function is defined there can 
be mutable variables, as long as they are not needed to type the body of the 
function. Moreover, the body of the function could contain bound mutable 
variables. This is enforced in the second row of the premise, by checking 
that the environment I’, in which the body of the function is typed, does 
not contain any declaration y:T”! for some y and T”. 

In the rule (TyLer), in typing e2 the variable x is bound to the type of the 
expression ¢,, and in the rule (TyMut) in typing eg the variable y is bound 
to the type of the expression e, followed by !, so that inside eg the variable 
y may be used on the left-hand-side of an assignment (see rule (TyAssicn)). 

Finally in rule (TyRsc), the variables in W are bound to the types in T, 
both in the typing of the body e of the construct, and also in the typing 
of their definitions F. Moreover, the type of the function definition, Fy, 
associated with wz, must be Ty (1<k<m). 

In this paper, we give a big-step semantics for the language with an 
explicitly typed evaluation stack for keeping the bindings of the immutable 
variables. Values and stacks are defined as follows. 

vo ou= n|tr|fls| (fun 2:T>e,c) | (let rec U:T=F in F,,c) value 
o z:THou,a|o stack 


I 
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“e:Tyel 
——————- (Tvvar) [TE n:int (TyNum) TE tr,fls:bool (TyBoot) 
Ie aes crea be 


/ * 7 . 
Thre, :int Db. e:int Mel] e:T 


(TySum) Voy ysl ge I! ied 
Tb ey+e9 : int ' [ml ol pe 
T’]+ fun 2:T’>e: T’ 3 T 
ThFe:bool Tre: T Pre: T Tke:T”3T Tee: T’ 
(TyIF) (TyApP 
T+} if e then e; else 2: T Thee: T 
Tke:T’ Tre:T Tre: T w:T!eT 
(TySEQ) _ (TYAssicn) 
Tre,e:T Trace: T 
Teg ¢ 2! Dg ree Tfo:T]) HK} F:T T[w:T]hke:T 
; (TYLET) ——— (TYREc 
[Fr let 2:T"=e, in eg: T TF let rec w:T=F ine: T 
Tre: TT Tybee: T 
(TyMut) 
TF let mutable y:T=e, ine: T 
Tre: TE Thre: T Tfa:Te]) ee: T 
—_—_———_ (Ty Turow) (TyCatcu) 
TF raisee:T [TF try ey with > e:T 


Figure 2: Typing rules for core F# 


Function values contain their definition stack, i.e., are closures. For 
recursive functions the definition stack of the functions F; should include 
the definition F; itself. To break circularity we use the let rec construct 
for the expression part of the value of mutually recursive functions. 


The domain of a stack dom(c) is the set of variables x such that 
z:T4v € o. For stacks we use the override notation o[o’] as for type 
environment. 


The set of free variables of a value v = (e,%:T'37) is defined by: 
FV(v) = (FV(e) — {&}) U FV(®). 


The standard a-conversion of functional languages, i.e., 


fun 2:T>e=,fun 2:T>elx:=z] 2 ¢ FV(e) 
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is extended to values with the transitive closure of the following rule 
(e, 2: T0)=o(e[x; := 2], [21 -°* G12 Zi41-+++In:THU)) z¢ FV(e,c)vU {z} 


Equality of values will be considered up to a-conversion. 

The lookup function that follows, given a variable and a stack, returns 
the value associated with the variable in the stack, if any. It handles recursive 
function values by returning their body and a stack in which the names of 
the mutually recursive function are bound to their recursive definition. 


Definition 1 The lookup function, dubbed lkp(c), is defined by: 


e lkp(a,o[2: TH) = (Fr, oli: Tin (let rec w:T=F in F;,0)|1<i<m), 


if v = (let rec pe in Fy, oc) 
e lkp(z,a[2:THul) = v, of v is not a recursive function, 
e ikp(z,o[2':THu]) = lkp(2,0) ifx Ax’. 
The type environment associated with o, dubbed env(c), is defined by: 
env(0) =0 env(a[x:Tv]) = env(a)[a:T] 


Core F# has imperative features, so for the definition of the operational 
semantics we need a store which is a mapping between locations and values: 


hr u,.--,ir t+ Un 


With p[z +> v] we denote the mapping defined by: p[z +> v](x) = v and 
ple H+ v](y) = p(y) when a # y. 

The runtime configurations are triples “runtime expression, stack, store”, 
(e | o |p), where the runtime expressions are defined by adding the clauses: 


en=---|lll<e 


to the grammar of expression of Fig. 1. In Fig. 3 we give the rules for the 
evaluation relation, |}, that given a runtime configuration produces a pair 
“value, store”, which is the result of the evaluation of the expression. In 
particular, (e | 7 | p) 4) (v | p’) means that the evaluation of e with the stack 
a, in the store p produces the value v, and modifies the store to be p’. 
Evaluation of a variable produces the value returned by the lookup 
function applied to the evaluation stack, rule (Var-F). Evaluation of an 
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lkp(z,0) =v 


e nVe 


trVe=fls 


(VaR-F) (PR-VAL-F) 
(x|o| p) d(x] p) (e|o|p) 4 (ele) 


ALF) _ Oe... a 
Pea ielavela 
(er |o | p) 4 (rm | pr) 


(e2 | o | p1) 4 (ne | p2) 


(ete |o| p) 4 (n | p2) 
(e|o| p) de (tr | pr) 


(SuM-F) 


(er | 7 | pr) 4 (v | p2) 

(Ir-TRUE) 
(if e then e; else e2 | a | p) |} (v | p2) 
(e|o| p) ¥ (£18 | p1) 


(e2|o| pi) ¥ (v| p2) 
Ir-F Ls 
(if e then e; else e2 | a | p) |) (uv | p2) 
(er |o| p) } ((fun 2:T>e,0’) | pr) (e2| o| pr) 4 (v | p2) 
(e | o'[x: Tr} | po) Y (v" | ps) 
(e1 eg |o| p) ¥ (v" | ps) 
(er | o| p) 4 (um | p21) 


(App-F) 


(e2 | a | pi) (v2 | p2) 
(SEQ-F) 

(e1, €2|a | p) } (ve | p2) 

(er |o| p) 4 (v | pr) 


(e2 | o[:T+0] | pr) 4 (v" | 2) 


(LEtT-F) 
(let 2:T=e1 in e2 | o| p) | (v" | p2) 
(er | o | p) Ye | p21) 


(ealy = Uo | pill v])4(v" | p2) UE dom(p1) 
(let mutable y:T=e1 in e2| 0 | p) 4 (v’ | p2) 


(LeTMut-F) 


(e | o[wi:Ti4(let rec w:T=F in Fj, c)]i<i<n | p) | (v | pr) 


=o (LETREC-F) 
(let rec w:T=F ine|a|p) 4 (v | pr) 


(e|o| p) 4 (v| pi) 


(Ass-F) 
(le |o| p) ¥ (v| pill v)) 


Figure 3: Big-step operational semantics for core F# 
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(e] |p) 4 (v | px) 
 (THROW-F) 
(raise e| o| p) I (E(v) | px) 


(er |o| 9) 4 (v | pr) 


(CTHVAL-F) 
(try ey with z > eg |a| p) | (uv | pi) 


(er | o |p) ¥ (E(er) | p21) (e2 | of: Terai] | 01) ¥ (v | 92) 
_—S S$. MM (CTHEXC-F) 


(try e1 with zg > eg|a| p) te (v| pe) 


(er | o | e) 4b (E(v) |p’) Vv 
( (er |o | ) ¥ ((fun a:T>e, 0’) | pi) A (e2| | pi) 4 (E(v) | 0") ) Vv 
(e1|o|p) ¥ (fun 2: Te, 0")|p1) A (e2|o|p1) 4 (| p2) A (el o" [+40] | p2) 4 (E(x) | 0’) 


(er ex | o| p) ¥ (E(w) | p’) 


(PRAPP-F) 


Figure 4: Big-step operational semantics of exception constructs 


integer or a boolean value produces the value itself, rule (Pr-VaL-F), whereas 
to produce a function value from a function expression, in rule (FN-VaL-F), we 
associate the function with its definition stack. (For recursive functions this 
is done with rule (Lerrec-F).) Evaluation of a location, rule (Loc-F), produces 
the value associated to the location in the store. The evaluation of the sum 
expression evaluates the operands of the expression, and then returns n, 
which is the numeral corresponding to the sum of the values of such operands 
nm, and ng. With n we denote the integer value corresponding to n, and with 
+int the sum operation between integers. For the conditional expression 
we first evaluate the condition and then return the evaluation of the then 
or else branch depending on the (boolean) value of the condition. For an 
application, rule (App-F), we first evaluate the expression on the left, which 
result must be a function value, then we evaluate the actual parameter, 
and then return the result of the evaluation of the function body. The 
evaluation stack for the body is the definition stack of the function on which 
we add the association between the formal parameter x and the value of 
the actual parameter. Similarly for (Let-F), where the definition stack of the 
expression is the current evaluation stack. Instead, for a mutable variable, 
rule (LeTMut-F) , a new location | is generated, added to the store with the 
initial value given by the evaluation of the expression associated with y, and 
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the occurrences of y in the body of the construct are substituted with such a 
location. Between these occurrences there are the variables on the left-hand- 
side of assignments. Indeed, since in well-typed expressions variables on the 
left-hand-side of assignments were always introduced by let mutable, when 
an assignment is evaluated, rule (Ass-F), we have a configuration: (l<e | p) 
which is evaluated by changing the value of the location / to be result of 
the evaluation of e. The evaluation of let rec, rule (Lerrec-F), produces 
the result of the evaluation of the body e with an evaluation stack, o’, 
which is the current stack, 0, to which we add the associations between 
the names of the recursively defined functions, w;, and the function values, 
(let rec w:T=F in F;,c), so that the evaluation of an occurrence of w; in 
e will produce the evaluation of F; with the stack o’, as it should be. In 
Fig. 4 we define the rules dealing with exception generation, and handling. 
Exceptions are generated by raise e, rule (Turow-F), and caught by the 
try e, with x > e2 construct. If the evaluation of e, produces a value, then 
the construct evaluates to such a value, instead if the evaluation of e; raises 
an exception with value v, then the expression e2 is evaluated, after binding 
xz to v, rule (CruExc-F). The propagation rules are obvious. We show only 
the one for application. 

We say that a configuration (e | a | p) converges, dubbed (e | a | p)4}, if 
either (e | 0 | p) I} (uv | p’) or (e | a | p) 4b (E(v) | p’) for some v, and p’. 

The typing rules in Fig. 2 are for the (source) expression language, so 
they do not include a rule for locations. To type runtime expressions we 
need a store environment © assigning types to locations. The type judgment 
is: 


Dee 2 
and the typing rule for locations and assignment to a location are: 


Pee esa 
[| SEI: (1) (tTybocF) (TT YAssicnLoc) 
Seer 
All the other rules are obtained by putting [| © on the left-hand-side of “+” 
in the typing rules of Fig. 2, except for rule (TyAss) which becomes: 
Pige Dl Ores 2" Vy, T" y:T'! € I" 
I] | Xt fun z:T>e: T > T’ 


(TyABs) 


In the following we define well-typed configurations, and prove the soundness 
result, which is derived from a big-step semantics version of the Subject 
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Reduction and Progress lemmas that follow. The soundness of the type 
system is essential for the proof of correctness of our translation. 

In order to define well-typed runtime configurations, we have to define 
well-typed values, stacks, and stores. The definition of well-typed values and 
stacks are mutually recursive, however there is no circularity, since stacks 
contain types and are subterms of function terms. 


Definition 2. 1. An F# value v has type T, dubbed — v:T, 


(a) 4fo=n, then. T =Ant 
(o) if v =tr or v= fls, then T = bool 


(c) if v = (fun 2:T, +e, <0), then for some Tz we have T = T, > To, 
env(o) | 0+ fun 2:T;>e: T, > To, and Ea 

(d) if v = (let rec Z:T=F in Fj,0), then Tf = T,, os; and for 
GU 5, Vs 7 Sn enete) |e: 7) | 0 Fj Ts. 


2. A stack o is well-typed, dubbed — o¢, if for all z:Tovu € 0 we have 
that - u:T. 


3. An F# store p is well-typed with respect to a store environment », 
dubbed %& —& p, if dom(p) = dom(S), and for all l € p we have that 


& p(l):5(0). 

4. The F# configuration (e | o | p) is well-typed, with respect to ©, dubbed 
UE (e|a| po, if 

(a) env(o)| Xt e: T for some T 

(b) Foe, and 

() BE p. 


Evaluation of well-typed configurations preserves well-typed stores, and the 
type of expressions. 


Lemma 1 (Type Preservation) Let (e|a@| p) be such that 4 — (e|oa | 
po. If(e|a| p) i (u| p’), then — u:T where env(c)| Xt e: T, and x! — 
p’ for some X! DX. Moreover, if T = Ty > To, then v = (fun 2:T,>e’, 0’) 
for some e’ and o’. 


Proof The proof of the lemma is given in Appendix A. 
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Also evaluation of a well-typed configuration resulting in exceptions preserves 
well-typed stores, and the type of the value associated to exceptions. 


Lemma 2 (Type Preservation for Exceptions) Let (e || p) be such 
that UE (e|a| p)o. If (e|a| p) (E(u) | 0’), then & vu: Te, and x! & p’ 
for some X! D>™. 


Proof The proof of the lemma is given in Appendix A. 


A big-step semantics is convenient for the proof of correctness of the trans- 
lation, however, it has the disadvantage of not distinguishing between non 
terminating programs and programs that “get stuck”. In our previous pa- 
pers, [12] and [14], we defined a small-step semantics which ensures that 
well-typed programs do not “get stuck”. Here, following [19], we give a 
coinductive characterization of the divergence judgment (e | o | p){}. The 
divergence judgment (e | o | p)‘} is defined in Fig. 5, where the rules have to 
be interpreted coinductively, i.e., they define infinite derivation trees. The 
rules are obvious. 

The following lemma asserts that our operational semantics is consistent, 
in the sense that given a configuration (e | a | p) if (e| a | p)J), ie., either 
the rules of Fig. 3 or Fig. 4 are applicable, then it is not the case that 
(e|a| p)tt, ie., the rules of Fig. 5 are not applicable. Moreover, if (e | | p) 
converges to a value then it cannot generate an exception. 


Lemma 3 (Consistency) Given a configuration (e| a |p), if (e|a| ppd, 
then (e | oa | p)tt is not derivable. Moreover, if (e | o | p) J) (uv | p’) for some 
v and p’, then there is no E(v’) and p" such that (e | o | p) tt (E(v’) | p”). 


Proof The proof of the lemma is given in Appendix B. 


The progress property says that well-typed configurations do not “get 
stuck”. The lemma, that follows, asserts such a property by showing that, 
for a well-typed configuration (e | o | p), either (e | a | p)) or (e | o | p)tt. 
That is, if no rule of Fig. 3 or Fig. 4 is applicable to (e | a | ), then the 
configuration diverges according to the rules of Fig. 5, i.e., (e | o | p)1} is 
provable. 


— 
fay} 


Lemma 4 (Progress) Let (e|o | p) be such that 5 & a | p)o. Either 


(e|o| pp} or (e|o| p)t. 


Proof The proof of the lemma is given in Appendix B. 
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(alolp)t V ( (erlol|p)}(m| pi) A (e2| oe] pi) ) 
(Sum-ft) 
(e1+e2|o| p)tt 
(elole)t Vi ((felol pd (tr| pi) A (er|o| pit) v 
((e|o|p)d (f1s| pi) A (e2 || p1)t ) ) 
IF- 
(if e then e) else e2 | a | p)tt =7 
(erlolp)t Vv 


( (er | o| ) } ((fun #:T>e,0') | pi) A (e2|o| pi)t ) 


V 
(e1|o| p) | (fun 2:T>e, 0’) | pr) A (e2 | o | pr) (v | p2) A (e | o'[z- 0] | p2)tt 
(App- 
(a alelet : 
(alolp)t Vi ( (er lol pd (a | pi) A (e2 |e] er)? ) 
(SEQ-f) 
(e1, €2 | o | p)th 
(alolpt Vi ((ele|p) 


(u | pi) A (e2 | ola: Trev] | pi) ) 
(LET-1t) 
(let 2:T=e, in e2 | o | p)t : 


(earlo| pt Vv 
(erl|o|p)¥ (vl pi) A (ely:=Jl ol mill ov) 


1g dom(p1) 


(LeTMut-1t) 
(let mutable y:T=e1 in e | a | p)t 


(e | o[wi: Tit (let rec w:T=F in Fi,o)}i<i<n | p)t 


——— (LETREC-{h) 
(let rec U:T=F in e|oa|p)tt 


(elo | pt 
(Ass-th) 
(raise e|a| p)t 
(er | o | p)tt 
(CTHVAL-{}) 
(try e, with z > e2|0| p)tt 


(er | | p) 4 (E(%) | px) 


(THROW-‘}) 


(e2 | o[a: Tei] | pi) tt 


(CTHYEs-‘}) 
(try e1 with t > e2|0| p)tt 


Figure 5: Coinductive characterization of divergence 


Soundness of the type system for the big step semantics is expressed by 
the following theorem. 
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Theorem 1 (Soundness) Let (e | o | p) be such that % — (e | o | p)e, 
and enu(o) | Ste: T. Either 


e (e|a|p) (vu p’) where — v:T or 
e (e|a| p) | (E(x) | p') where E v:Te or 
e (e|o| pt. 


Proof Let (e | o | 9) be such that © — (e|o| p)s, and env(o) | NF e: T. 
From Lemma 4 either (e | 0 | p)} or (e | a | p)tt. Assume that (e | a | p). 
If (e | o | p) J (v | p’), then, from Lemma 1, we have that — v:T. If 
(e|a |p) } (E(v) | ’), then, from Lemma 2, we have that — v:Te. 


Let Loc(e) be the set of locations occurring in the expression e. An F# 
program is a well-typed closed expression e such that Loc(e) = @. The initial 
configuration associated with a program is (e | @ | []). From Theorem 1 
either (e | @ | []) 4) (vw | p) where v has the same type of e and © E op for 
some , or (e | @ | [])*. 


3 Intermediate Language 


In designing IL our goals were: on one hand to have a language close enough 
to the structure of the target languages (JavaScript and Python), and on the 
other to allow us to give a translation simple enough to be formally proved 
to preserve the semantics of the original language. 

Our IL is an imperative language with three syntactic categories: ex- 
pressions, statements and blocks. We introduce the distinction between 
expressions and statements as many target languages do. This facilitates the 
translation process and prevents some errors while building the intermediate 
abstract syntax tree (see [4] for a similar choice). The block structure is 
inspired by IntegerPython (see [21]). Variables are statically scoped, in the 
sense that, if there is a definition of the variable x in a block, all the free 
occurrences of xz in the block refer to this definition. However, we can have 
occurrences of x preceding its definition. This feature, present in Python, 
is useful, for the translation of the letrec construct. As in Python and 
JavaScript closures are expressions, but sequences of expressions are not 
expressions, as this is a feature that could not be present in the target 
language. The constructs for handling exceptions are modeled to be similar 
to the ones of Python and JavaScript. 
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3.1 Syntax and Semantics of IL 


In the syntax of IL, given in Fig. 6, there are three (main) syntactic categories: 
blocks, statements, and expressions. 


bl ::= {se} block 
se i= st|e|se;se sequence 
st := ux<e|def r:=e|try bl catch(z) bl statement 
e u:= 2|n|tr|fls|fun «>0dl|e+e|if e then bl else bl 

|e e| raise e expression 
vo ou= n|tr|fls | fun s>5bl value 


Figure 6: Syntax of IL 


Blocks are sequences of statements or expressions, enclosed in brackets. 
In our translation we flatten the nested structure of let constructs so 
we need blocks in which definitions and expressions/statements may be 
intermixed. Moreover, since we do not have a specific let rec construct use 
of a variable may precede its definition, e.g., when defining mutually recursive 
(or simply recursive) functions. Statements may be either assignments or 
variable definitions or the constructs of exception generation and catching. 
Our compiler handles many more statements, but these are enough to show 
the ideas behind the design of IL. Forward definition in a block are permitted, 
E.g., 


{ def f=fun y->{x}; def x=5; (f 2) } 
correctly returns 5, whereas the following code would produce a runtime 
error: 


{ def x=7; 
if (x>3) then { def f=fun y->{x}; (f 2); def x=5; 3 } 
else { 4 } 


} 


since when f is called the variable x, defined in the inner block, has not 
yet been assigned a value. Instead, if x was not defined in the inner block, 
like in the following 


{ def x=7; 
if (x>3) then { def f=fun y->{x}; (f 2) } 
else { 4 } 
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the block would return 7, since x is bound in the enclosing block. This is 
also the behavior in JavaScript and Python. Values are integers, booleans, 
and functions (as for F#). 

In Fig. 7, we define the free variables of expressions, sequences, and 
blocks ( FV(e), FV(se), and FV(bl)). Note that, the assignment statement 
does not define the assigned variable, which is free in the statement. 


e FV(e), is defined by 
— FV(a) = {x} 
— FV(n) = FV(tr) = FV(f1s) = 0 
— FV(fun r>0l) = FV (bl) — {x} 
— FV(e\+e.) = FV(e, e2) = FV(e,) U FV(e9) 
— FV(if e then bl, else bly) = FV(bl1) U FV(bl2) U FV(e) 
— FV(raise e) = FV(e) 


e FV (se), is defined by 
— FV(a<e) = FV(e)U {x} 
— FV (def x:=e) = FV(e) 
— FV 
— FV 

e def(se) is defined by 

z<e) = def(e)=0 

def r:=e) = {x} 

$€1; 8€2) = def (se,) U def (sez) 


Figure 7: Free variables of expressions and blocks 


The operational semantics of IL is given by defining evaluation relations, 
for the syntactic categories of IL. In particular, we define 1}y) for blocks, {) sq 
for sequences, {|.¢ for statements and |}. for expressions. Configurations will 
be pairs, “(C' | p) ”, in which first component is a syntactic construct: block, 
sequence, statement, or expression and the second a store. As for F# we have 
to add to the syntax of expressions locations, I, as they are generated during 
the evaluation of blocks. The syntax of the runtime language is generated 
by adding the clauses for expressions and statements that follows: 
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st 
e 


-+-|l<e| def l:=e 
eel 


The rules of the operational semantics are defined in Fig. 8. 


(sefe:=T]| p47) Voq(v lp’) {2} = def(se) {1} dom(p) = 0 


(BLock) 
({se} | 2) Yoru | p’) 
(se1 | p) Vsq(1 | p1) (ea | pi) Ysq(v2 | p2) as 
EQ 
(s€1; €2 | p) Isq(v2 | p2) 
(st | p) Yse(v | p’) (e| p) Yea(v | p’) 
: (ST) ; (Expr) 
(st | p) bsq(v |p’) e| p) bsalv | P 
(e | p) Yex(v | p1) (e | p) dea(v | pr) 
5 (DEF) 


(ela) Valo |mlia a) Get Ee |p) dale | aalte op) 


ooo (VAL) ne Ee 

(v | p) Vea(v | p) (1 | 0) ealv | p) 

(ey | p) Yeea(m1 | p1) (e9 | 1) Yea(ne | p2) aA=iy int ino 
(er +e2 | p) Vea(n | p2) 


(| p) Yea(v | pr) 
(v=tr A (bli | pi) Yuu | p2)) V (v= f1s A (ble | pr) Yoru | p2)) 


(if e then bl, else bla | p) Yex(v | p2) 


(Sum) 


(IF) 


(er |p) Yex(fun c>bl| pi) — (e2 | pr) 
(bl[x := 1] | pall v]) Yov’ | es) 


(€1 €2 | p) Yea(v' | ps) 


Figure 8: Big-step operational semantics for IL 
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(raise e | p) \lex(E(v) | p’) 


(TRow) 


(bla | p) Yoav | 6’) 
(try bly catch(a) blo | p) Ise(v | p’) 
(bli |p) Yor(E(v) | pr) (blo[a := U] | pill v]) Yor(v" | p2) 1 dom(p1) 


(try bly catch(a) blo | p) Ise(v’ | p2) 


(CTHVAL) 


(CTHEXc) 


(ser | p) Ysa(E(v) |p’) V ( (ser | 0) sav | 01) A (se2 | p1) Ysa(E(v) |p’) ) 


(PRSEQ) 
(se1; se2 | p) Ysq(E(v') | p’) 
(e1 |p) Yex{E(v) |p") V ( (er | p) Yex(fum x->bl | pi) A (e2 | p1) tee(E(v) |p") ) V 
(e1 | p) Yee(fun tbl | pi) A (e2 | 1) Yee(v | p2) A 
(bila = 1] | poll v]) Yor(E(v) | o) ) 
———S S$. A (Perl 


(e1 €2 | p) bea(E(v) | p’) 


Figure 9: Exception generation, handling an propagation in TL 


The first rule, (BLock), defines the evaluation of a block. We first allocate 
the locations for the variables defined in the block and then return the result 
of the evaluation of the sequence of statements or expressions of the block. 
The function def (se) mapping a sequence to the set of variables defined in 
it is defined in Fig. 7. We want to model forward declarations in blocks and 
the fact that the evaluation of an access to variables before it is assigned a 
value is not permitted. To this extent, the initial value of the location is set 
to undefined, ?, so that an access to this location before the evaluation of 
an assignment or a definition for the corresponding variable would be stuck. 
Note that, this will never happen for IL programs which are translation of 
F# programs. After this initial allocation a closed block will not contain free 
variables. 

The evaluation for sequence of statements or expressions is obvious. 
Rules (Ass) and (Der) define the evaluation of a statement. They both modify 


A Provably Correct Compilation of Functional 
Languages into Scripting Languages 37 


the location on the left-hand-side to the value resulting from the evaluation 
of the expression on the right-hand-side. So, after this, the value of | is no 
longer undefined. 

The remaining rules define the evaluation of expressions. Rule (Vat) returns 
the value and rule (Loc) the value contained in the location. The rules for + 
and if are obvious. In rule (App), we first evaluate the expression on the 
left-hand-side, which must result in a function, then the actual parameter of 
the function is evaluated. A location is allocated in memory, assigning to 
it its value and the location is substituted for the formal parameter in the 
body of the function. Note that, being in an imperative language, the formal 
parameter could be modified in the body of the function, however, this 
change would not be visible in the calling environment, since the location is 
new. Finally, the body of the function is evaluated. 

In Fig. 9 we define the rules dealing with exception generation, and 
handling, which are similar to the ones for F#. We only show the propagation 
rule for sequencing and application. 

Let C be an IL syntactic construct or E(v) for some v, Loc(C), is the 
set of locations occurring in C’. We define well-formed configurations. 


Definition 3. 1. An IL store p is location closed if | € dom(p) implies 
that FV (p(l)) =, and Loc(p(l)) C dom(p). 


2. The IL configuration (C | p) is well-formed if p is location closed, 
FV(C) =9, and Loc(C) C dom(p). 


The operational semantics of Fig. 8 preserves well-formed configurations, as 
the following theorem states. 


Theorem 2 Let (C'| p) be well-formed, if (C | p) \_ (C’ | p’), then (C" | p’) 
is well-formed. 


Proof By induction on the derivation of |}. We consider only the rules, 
(BLock), and (App). For all the other rules the result follows from the induction 
hypotheses. 


Rule (Block) From ({se} | p) well-formed we have that p is location closed, 
FV ({se}) =, and Loc({se}) C dom(p). From FV ({se}) = 0 we have 
that all the variables occurring in se are in def(se) = {7}. Therefore 
FV(se[z := l]) =0, Loc(se[x := 1]) C dom(p[l 4 7]), and p[l + ?] is 
location closed. So (se[¥ := I] | p[l > ?]) is well-formed. 

Let (se[z := 1] | pll ++ 2]) Ysq(v |p’) ((selz =f | ll 7]) Ysq(E(a) | 
p’)), by induction hypothesis (v | p’) ((E(v) | p’)) is well-formed. 
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Rule (App) From (e; €2 | ») well-formed we get that p is location closed, 
FV(e,) = 9, FV(e2) =, Loc(e,) C dom(p), and Loc(e2) C dom(p). 
Therefore (e; | p) is well-formed. 

Let (e1 | ?) \ex(fun > bl | p1), by induction hypotheses (fun «Dl | 
pi) is well-formed. Since dom(p) C dom(p1) we have that Loc(e2) C 
dom(p1), 80 (€2 | p1) is well-formed. 

Let (e2 | p1) ex (v’ | p2), by induction hypotheses (v’ | p2) is well- 
formed. 

From (fun z—>bl | 1) well-formed we have that FV(bl) C {zx}, 
and Loc(bl) C dom(p,), so also Loc(bl) C dom(p2). From (v’ | p2) 
well-formed we get FV(v’) = 0, and Loc(v’) C dom(p2). Therefore 
FV(bl[xz := 1) = 0, poll v'] is location closed, Loc(bl[x := I]) C 
dom(p2{l +> v‘]), and (bl[a := 1] | p2[l > v']) is well-formed. 

Let (bl[xz := 1] | po[l + v’]) der(v | p'), by induction hypotheses (vu | p’) 
is well-formed. 


An IL program is a closed block, bl, such that Loc(bl) = 0. The initial 
configuration for a program is ({b/} | []). An initial configuration is well- 
formed. From Theorem 2 we derive that the execution of an IL program 
produces a well-formed configuration. 


4 ‘Translation 


Many F# constructs can be directly mapped to JavaScript (or Python), but 
when this is not the case we obtain a semantically equivalent behavior by 
using the primitives offered by the target language. For example, 


let mutable x = 3 in 
let z= x in 
x <- xt+1, z 


is translated in the following sequence 


def x := 3; def z := x; x <- xtl; z 


Note that, we do not distinguish immutable from mutable variables and the 
let construct is flattened in sequence starting with the definition of the 
let-bound variable, followed by the translation of its body. 

In F# a sequence of expressions is itself an expression, while in Python 
it is a statement. We translate a sequence of expressions with a sequence 
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of statements. However, if the original expression was used in a context 
in which a statement is not allowed, we have to provide a way to refer to 
the value of the expression. Moreover, as we saw before a let construct is 
translated in a sequence of statements and expressions. For example, in the 
translation of 


let mutable x = 3 in 
let z= x <- xtl, x in 


Z 
we cannot assign to the variable z a sequence of expressions, since 
def z:= ( x <- xt+l; x ) 


is not a correct definition. To overcome this problem, in the translation we 
define a (new) variable which contains the value of the expression. In the 
previous case, 


x <> xt x 


is translated to 


x <- x+1; def zl := x; 


indicating that z1 holds the value of the expression. The translation of the 
whole expression is 


def x := 3; x <- x+1l; def zl := x; def z := zl; z 


To make the translation uniform we always define a new variable, holding the 
value of the expression, also for the cases in which the translated expression 
is already an expression. For example, even though it would not be necessary, 
also the translation of expressions 3, x, x+1, generates a new variable. So 
the formal translation would be 


def xl := 3; def x := x1; 
def x2 := x; def x3 := 1; def x4 := x2 + x3; x <- x4; 
def x5 := x; def z= x5; 


def zl = z; zl 


where all the variable followed by a digit are generated by the trans- 
lation. The first line translate x = 3, the second x <- x+1, the third 
z = (x <- x+1, x) and the last one the body of the inner let, ie., the 
expression z. 

We could avoid the generation of the unneeded variables by giving two 
translations, one that produces an expression and another that produces 
a sequence, as in our previous work [14]. However, the uniformity of the 
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translation simplifies the formal proof of correctness, which is the aim of 
this paper. 


4.1 Formal Definition of the Translation 


In the following we give the translations of an F# expression, e, into IL. The 
translation is parametric in the sets of variables J and M, which are the 
immutable (J) and the mutable (/) variables defined in the context of e. 
The translation produces a sequence of IL statements and/or expressions, se, 
and a variable, z, which holds the value of the translation of the expression 
e. Tracing mutable and immutable variables is needed for the proof of 
correctness, but it is avoided in the implementation. 


Definition 4 Let e be an F# expression such that &:T, yt! |@t e: T for 
some T and let I = {z} and M = {y}. The function [e]’™ is defined as 
follows: 


1. if eis n or tr or fls or z or l, then [e]’™ = (def z:=e,z) 
where z is a fresh variable; 


2. [fun x:T>e']'™’ = (def z:=fun r>{se},z) where z is a fresh 
variable, and [e']{Ut*}“=( se, z’); 


B: ey te]?! = ($e); seg;def z:=(z1+2%),2) where z is a fresh variable, 
and [e]j’™” = (sei,%) <i < 2); 


4. [er ea]’™ = (se1; seg; def z:=(% %),z) where z is a fresh variable, 
and [e]’-™ = (se:,%) <i < 2); 


5. [if e, then eg else es)!” = 
(se1;def z:=_;if 2 then {se2;z<-z} else {se3; z<-23},z) where z 
is a fresh variable, and [e]'’™ = (sei,%) (1<i< 3); 


6. [e1, e2]’™ = ( sei; se, 22) where z is a fresh variable, and [e]’“ =( se;, z; ) 


(lt 2): 


7. (a) ifx €IUM, then 
[let z:T=e, in e (se;;def r:=2; seo, 2) 
where [ey =( se1, 2), and [eg Utt} —( seo, 22); 
(b) fx EIUM, then 
[let 2:T=e, in eg]’” = [let w:T=e, in (e9[z := w])]™ where 
w is a fresh variable; 


[2% = 
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8 (a) ify ¢IUM, then 
[let mutable y:T=e, in eg]’™ = ( sei; def 2:=2; sea, 2%) where 
[ery =( sei, 1), and [eo]? @Ut4t =( seo, 22); 
(b) ifyEIUM, then 
[let mutable y:T=e, in ep 
[let mutable w:T=e, in (e2[y := w])]’™ where w is a fresh va- 
riable; 


yi@ = 


9. (a) if {W}N (TUM) =9, then 
[let rec w:T=F in e]’™” = (se1;--- 3 sem;def W:=7; se, %) 
where [Fj]247}™ = ( sej,2z;) (1 <j <m), and [eft =( se, ~); 
(b) if {w}N (TUM) FJ, then 
[let rec w:T=0 in e]’™” = 
[let rec 7:T=(0[w := W’]) in (e[w := w'])]'™ where w are fresh 
variables; 


10. [y<e’}’™ = (se; y<z,z) where [e’]’™“ =(se,z); 


11. [raise e']’™ = (se;raise z,z) where [e’]’™“=(se,z); 


12. [try e with > e)/” = 


(def z:=_;try {se,;z<-2} catch(2) {seg;z<z},z) where z isa 
fresh variable, and [e]'’™ = (se;,z%) (1 <i < 2). 


Translation of constants, locations and variables is the identity, see 
clause 1 of the previous definition. The variable returned is initialized to 
the expression. The translation of functions, clause 2, produces a function 
whose body is the translation of the body into an IL sequence of the original 
function. In the translation of the body of the function, e’, the variable zx 
is added to the set of free immutable variables of the context of e’. The 
variable returned is initialized to the translation of the function. For sums 
and applications, clauses 3 and 4, we first translate e, and eg, getting the 
sequence of IL statements se, and seg and the variables z and zg, that can 
be used to refer to the value of the expressions e; and eg. In the sequence 
produced we first have the evaluation of se ,, then se2, and finally the 
definition of a new variable z, initialized to the sum (respectively application) 
of z, and zg. So, the translation reflects the left-to-right evaluation of the 
constructs. For the if construct, clause 5, the translations of the condition 
and then/else branches produce the sequences of IL statements se; and the 
variables z (1 <i <3). The translation is then defined by the evaluation of 
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the condition se, followed by the definition of a new variable z, to which 
it is assigned the result of the evaluation of the then/else branches. Since 
the branches are blocks, to be visible the variable has to be declared outside 
the blocks. We use _ to indicate any default value. The translation of the 
then/else branches is given by the sequence of the IL statements followed 
by the assignment of their resulting value to the variable z. The translation 
of a sequence, clause 6, is the sequence of the sequences of statements or 
expressions which are the translations of its subexpressions. The result is 
available through the variable z2, which is the variable holding the result of 
the evaluation of the second expression. 


The translations of the let constructs, clauses 7, 8, and 9, produce 
a sequence in which first the definitions of the variables are bound to 
the translation into expressions of the associated expressions, followed by 
the translation into a sequence of the body of the let construct. For the 
translations there are two clauses depending on whether the variables defined 
are or are not already present in the context. 
In case the variable zx is not defined in the context. The translations of 
the let and let mutable constructs, clauses 7 and 8 produce a sequence 
starting with the translation of the expression which is assigned to the local 
variable x. Then, there is the definition of the local variable x to which it is 
assigned the result of the evaluation of the expression e, which is referred to 
by the variable z,, followed by the translation of the body of the construct 
eg. For the translation of e2 the variable x is added to the immutable or 
mutable variables of the context depending on the fact that zx is introduced 
with the let or let mutable construct. The variable that holds the result 
of the construct is the same as the one holding the result of the translation 
of e€2. 
If the variable is already present in the context (either as immutable or 
mutable) the let or let mutable construct is a renamed substituting 
with a fresh variable w. This ensures that w is not in JU M and does not 
occur in the let expression. 
The translation of the letrec construct, clause 9, is similar to the one of the 
let construct, just considering the fact that instead of defining a variable 
we define a set of variables {w} (all immutable) and that the variables in 
{w} are also free in the function definitions F. 


The translation of assignment, clause 10, produces an assignment state- 
ment in which the variable is assigned the result of the translation of the 
expression on the right-hand-side of the assignment expression. 
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The translation of raising an exception, clause 11, is the sequence of IL 
statements translation of the expression associated to the exception, followed 
by the corresponding IL construct, with associated the variable that refers 
to the value of the expression. The same variable holds the result of the 
raise construct. 

The translation of the try-with construct, clause 12, produces the 
corresponding IL construct. The translations of the body of the try-with 
and the body of the catcher produce the sequences of IL statements se; 
and the variables z; (1 <i < 2). However, since the result of the evaluation 
could be either one of them and the variables z; are local, to refer to the 
value of the try-with expression we need to declare a new variable z, outside 
the blocks (similar to the translation of the if construct). Note that, if the 
expression ¢€; raises an exception the assignment z<-z, will not be executed. 

The correctness of the translation of the Let constructs relies on the fact 
that the renaming of variables used does not change the operational semantics 
of expressions. In the following lemma with o[z; := z] we denote the stack o 
in which 2; is substituted with z, i.e., [a --+ 2-12 Ui41-++ Mi: THI). 


Lemma 5 Let ¢ = 7:T+3% and (e | a | p) be such that S — (e | a | p)o. 
Let & = %,+++%,, be such that {z’} C {Z} and Z be fresh variables; (e | 
o |p) (v | pr) if and only if (e[z" := Z] | o[z" = 2] | p) i (v" | |) where 
v =v’, dom(p1) = dom(p)) and for all l € dom(pi), pi(l) = p4 (1). 


Proof By an easy induction on the derivation of (e | 7 | p) 4 (v | p’) using 
the fact that equality between values is up-to a@-conversion. 


4.2 Correctness of the Translation 


The translation preserves the dynamic semantics of the F# expressions. That 
is, consider an F# program e and its translation in then IL block 6/1. We want 
to show that the evaluation in F# of e has the same result of the evaluation 
of bl in IL. That is if e evaluates to a primitive value, v, bl evaluates to the 
same v, and if the evaluation of e raises an exception, then also b/ raises an 
exception. Moreover, if the evaluation of e diverges, then 6/ cannot either 
converge to a value or raise an exception. 

Given an F# program e, e J} v and e |} E(v) are abbreviations for 


(e| [] | []) 4 (| px) and (e | [] | []) 4 (E(x) | p+) for some p,. Similarly for 
IL blocks bi. 
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Theorem 3 (Correctness) Let e be an F# program, and let [e]®®=( se, z ). 


Then 


eel v for some v either integer or boolean value if and only if 
{ se;z} Uo, and 


e el} E(v) for some v if and only if { se; z } bwE(v’) for some v’. 


The proof of the theorem relies on Lemmas 7 and 8 and will be given at the 
end of the current section. 

To prove the result we define a translation relation between F# values 
and IL values and between well-formed configurations of F# and well-formed 
configurations of IL. Then we show that if the evaluation of an F# configura- 
tion converges, then the evaluation of the related IL configuration converges 
and the result is a related value, Lemma 7; moreover, if the evaluation of 
an F# configuration does not converge to a value, then the evaluation of 
the related IL configuration does not converge, Lemma 8. Therefore, since 
an integer/boolean value in F# is translated into the same integer /boolean 
value in IL this proves the result. 

Looking at the translation from F# to IL we can see that both immutable 
and mutable variables of F# are translated into IL (mutable) variables that 
are allocated in the store. Moreover, we introduce new variables to hold 
the result of expressions, see Definition 4. So, the store, p’, of a runtime IL 
configuration produced by the execution of the translation of an F# expression 
can be partitioned in two parts, p™” and p!, where p™ correspond to store 
of the F# configuration, containing the values of the mutable variables and 
p' records the values of the F# immutable variables and the new variables 
introduced. We assume that the names of the locations in p™ are equal to 
the corresponding ones in the F# store. Looking at the evaluation rules of 
Fig. 8, we can see that, the locations in p! will be assigned ?, by the rule 
(BLock), when they are allocated in the store, before starting the execution 
of the sequence of statements or expressions of the block containing the 
definition of the immutable variables. Then they are assigned a value, when 
executing the def statement associated to their definition. After this, the 
value of the associated location does not change (except for the case of the 
variable introduced for the translation of the if expression, where at the end 
of the chosen branch it will be assigned). 

To define the correspondence between an F# configuration and the IL 
configuration which arises from its translation we first define a translation 
relation between F# values and IL values. For function values, we need the IL 
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store since the (immutable) variables of the stack and the variables generated 
by the translation are translated in IL variables, which are, at runtime, 
allocated in the store. So we relate an F# value with an IL configuration 
containing a value. 

We assume equality between primitive values in F# and IL. In order 
to define the equivalence between an F# function value (fun z:T—e,o) 
and its IL translation, we have to establish equivalence between the F# 
values associated to variables in the definition stack o, and the IL value 
contained in the location of the IL store corresponding. Therefore, we give 
a coinductive definition. 


Definition 5 The translation relation between F# values and well-formed 
IL configurations, dubbed &, is defined by 


fon (n |p), tr =r |p), and: fle = (f1s |p) forall p. 


2. (fun 2:T>e,c) & ((fun >{se[x := I]}) | p) for some {1} C dom(p), 
where dom(c) = {x}, and 


(a) [e]dorm Utes 13} — ( se,z) for some Y, and z, and 


(b) for alli, 1 <i<n, let a;:Tjv; € 0, we have that vu; = (p(k) | p). 


3. (let rec w:T=F in F;,o) = (v{[wz:=T" I] | p) for some {1,1} C 
dom(p) where dom(o) = {Z}, and 


e forallj, 1\<j<m, 
(a) vi = fun x>{se;} where Fj = fun x:T)>e;, 
and feels A} = ( se;, 2) for some Y, and z, and 
(6) pl?) =u,[wr:=T I, and 
e for allp, l1<p<n, let tp:Tp>uy € o, we have that tp = (p(Ip) | 
p). 


Primitive F# values are related to IL configurations whose first com- 
ponent is the same primitive value. For F# functions, (fun z:T—>e,c), we 
require that the first component of the IL configuration be the translation 
of fun x: Te, in which the free variables of the body (a subset of dom(c)) 
are replaced with IL locations which are associated in the store to values 
that are translation equivalent to the associated value in a. For recursive 
functions we also must have that, in the IL store, the values associated 
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to the locations corresponding to the names, w, of the recursively defined 
functions in F’, are the translation of the functions in F’. 

The following lemma asserts that, if the value of a recursive definition 
is in the translation relation with an IL configuration, then the function 
value which is the result of the lookup function of Definition 1 is also in the 
translation relation with the IL configuration. 


Lemma 6 [f for alli, 1 <i<m, we have (let rec w:T=F in F;,c) = 
(ul [Ew:=TT"] | p’), then for all j, 1< 9 <m, we have 


(Fj, o[wi: Ti (let rec @:T=F in Fi,o)hi<i<m) = (v;[EW := TT’}| pe’). 


Proof Directly from Definition 5. 


We, now, define a translation relation between F# configuration, (e | a | 
p), and IL configuration, (se | p’), that holds if se is the translation of e, and 
the values of the mutable variables of e in the store p are in the translation 
relation of Definition 5 with the values of the corresponding variables in p’. 


Definition 6 The F# configuration (e | a | p) and the IL configuration 
(se | p') are translation related, written (e | o | p) © (se | p’), w.r.t. the 
location environment © = 1:T, the seu of disjoint variables T, Y, W, z, 
the sequences of disjoint locations T a Wir l,, and the F# expression e° if: 


1. = Xe-| o° | ps, (s eel ') is well-formed, {Z} = dom(c), {w} = 
def (se) — {z}, and 1’:T’ CE, 


2. e= ely := 1") where env(c),7:T'!| 0 e° : T for some T, 
3. se=se(EGWz:=0 UT 1) where feo] tF = ( se°, z), 


4. p' =p! +p™ for some p! and p™ such that dom(p) = dom(p™), and 
te Es, LL} SC dom(p'), 
5. for alli, 1<i<n, let x%:Ti4v; € 0, we have that v; = (p'(4") | p’), 


and 


6. for all | € dom(p) we have that p(l) = (p'(1) | p’). 


Theorem 3 asserts the correctness result for the execution of an initial 
configuration evaluating, if it converges, to a primitive value. To prove 
this result, however, we have to deal with the intermediate configurations 
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generated during the evaluation and with function values. To this extent we 
prove the following lemma, which asserts that configurations related by the 
translation relation evaluate to values and stores which are related by the 
translation relation. 


Lemma 7 Let (e|o| p) © (se| p’) w.r.t. S=1:T, the variables Z, 7, UW, 
z, the locations ie i ag L, and the F# expression e°. 


e If(e|o| p) 4 (v| ps), then (se | p’) Ysq(v" | pi.) where 


A) v= (v'| p,), and v' = pi (lz), 
B) for alll ¢ {1",1°, 1} we have that p'(1) = pl,(1), 
C) for alll € dom(p,) we have that p,(l) = (p/.(1) | p). 


e If(e|o| p)d (E(v) | pe), then (se | p’) Isq(E(v’) | p.), and properties 
(A), (B), and (C) hold. 


SERS eee 


Proof The proof is given in Appendix C. 


The following lemma asserts that if the evaluation of an F# expression 
does not converge to a value, then also the evaluation of a translation related 
IL sequence of statements or expressions does not converge to a value. 


Lemma 8 Let (e | 7 | p) © (se | p') w.r.t. N=U:T, the variables F, Y, W, z, 
the locations T’, 1”, T”, l,, and the F# expression e°. If (se | p’) Isq(v' | p'.) 
or (se | p') sq(E(v’) | p.), then (e | o | p) —+ BS(v | px) or (e | o | p) 4 
(E(v) | px) for some v and px. 


Proof By case analysis on the shape of e and then induction on the deriva- 
tion of (se | p") bsa(0" | pt). 

The base cases of e = xz, or e=n, or e=tr, or e=fls, or e=fun z:T’>e1, 
or e = | are obvious from Definition 6.2 and 3. 

For the structured expressions we only show the proof for application. 
The others are simpler. 

Let e=e, € for some e; and eg. Since e = e° [9 := ae then e°=e? e5 
where e; = e?[y := 1”]. From Definition 4.4 we get that [e°]{7}-7 = ( se°, z) 
where se° = se; seS;def z:=z 2%, [eo] {*}{9} = ( se2, a) (1 <i < 2), and 
z is a fresh variable (so cannot occur in se?). From Definition 6.3 we have 
that se is 

sei; 8e9;def l,:=(l,, |.) 
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where se; = seS(ryw' y= 7" 1,,], and {0,1 1", 1} C dom(p'). Mo- 
reover def(se°) = def(se{) U def(se5) U {z}, def(se{) N def(se§) = 0, and 
{a} = def (se2) — {a}. 

Assume that (se | p’) \bsq(v’ | p!.). Then 


e (ser | p') Ysq(r | p1), 
e (seg | op) sgt | Po), and 
e (def Ba Lb.) | i) A eho" | p)- 


From the properties of se; and e, we derive that (e; | 0 | p) © (sey | p’) w.r-t. 
v= 1:T, the variables 7, 7, w', z, the locations rhe iar l,,, and the F# 
expression e?. Applying the inductive hypothesis to (se; | p’) Isq(vt | p4) 
we have that (e1 | 0 | p) J) (v1 | 91) for some v, and p;. From Lemma 7 we 
derive 


(Ai) v1 = (uy | pi), a1 = pi (ln), 
(42) 1¢ (PT, 1,} implies p'(2) = p4(Z), and 
(A3) 1 € dom(p1) implies pi(1) = (p4(0) | 64)- 
Consider the configurations (e2 | 7 | p1) and (seg | p,). From (Ag), (Ag) and 
the properties of sez and e2 we derive that 
(e2 | o | pr) & (sea | p4)- (1) 


Applying the inductive hypothesis to (se2 | p) sq(v§ | ph) we have that 
(e2 | a | pi) 4) (v2 | p2) for some v2 and p2. From Lemma 7 we derive 


(Ai) v2 & (uh | 05), 0h = ph (len) 
(Ab) L¢ {1’,T, Ly} implies pi(J) = ph(J), and 
(Ay) Le dom(p2) implies p9(J) & (p(t) | ph). 


From (def 1,:=(l:, lz.) | 94) 4bsq(v" | o.) and the evaluation rules of Fig. 8 
we have that: 


({se’} [x := be] | poll: + v3]) dui(v" | px) 
where 1, ¢ dom(p4), and vj = fun r—>{se’}. Therefore, from the evaluation 
rule for blocks we get 


(se![xW! = lel] | phlle > WT” +9 FI) Vaal" | px) 
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where {w’} = def (se’), and Ty NM dom(p,) = 0. From (A,) and Definition 
5, for some e’, T’, and o’ we have that 


(Pi) ™ = (fun 2:T’Se',o’), 


(Paya = func fse le t= ra where {z’} = dom(o’), and {T"} Cc 
dom(p\), 


(P3) [el ]tome Uta} {9't — ( se”, 2’) for some 7’, and 2’, and 


(P1) for alli, 1<i<n, if af: Thou! € 0’, then uf! & (po) (i) |p). 


Consider the configurations (e! | o/[x:T’ + wv] | p2) and (se/[cW := LT” : | 


Polly, rigs ++ ?]). From (P3) we derive that conditions 2 and 3 of 
Definition 6 are verified. From (P,) and (A$) we have 


(P!) for alli, 1<i<n, if af: Thou! € 0’, then uf! & (o4(I7) | p4). 


So condition 5 of Definition 6 holds. Moreover, from (A) condition 6 holds. 
Therefore 


(e’ | o'[x:T’ + vw] | 92) & (se'[z Ww! := Le tT”) | 0o[be ei re 2}. (2) 


By induction hypothesis on (se’[zw’ := |, P | Pole > v4 ee Ty bee 
(v’ | px) we have that (e’ | o/[z:T’ +> w] | p2) 4) (uv | px), for some v and 
px. Therefore, from rule (App-F) of Fig. 3 we have that (e || p) 4 (uv | px), 
which proves the result. 

Assume that (se | p’) \)sq(E(v’) | p.). Then, by the propagation rule (PrSxq) 
of Fig. 9, we have 


(C1) (ser |p) Ysq(E(v’) | o%), oF 
(C2) (ser |p’) Yq | 1) and (see | pt) Ysq(E(v’) | pi), oF 


(C3) (ser | 0°) Lsalv | 1) and (sea | 01) Yoav | 62) and (det L:=(le, lap) | 
Pa) Vsq(E(v') | A) 


In all three cases the result derives by induction hypothesis and application of 
rule (PrApp-F) of Fig. 4. To apply the inductive hypotheses in cases (C2) and 
(C3) we need the equivalences (1) and (2), respectively. Such equivalences 
are proved as for the case of convergence to a value. 
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Proof of Theorem 3 (correctness): 
Let e be an F# program, then for some T we have that @|@t e: T and so 
0 (e || 0)o. From [e]®"=(se, z) we have that FV(se) = 0, and se does 
not contain any location. Consider the configuration (se’ | [l, 4?T” 1% ?]) 
where se’ = se[wz := T° 1]. The configuration is well-formed and it is 
translation related to (e | [] | []) w.r.t. the empty location environment, 
the empty sets for variables % and ¥, the sets of variables W and z, and the 
expression e. 

Let (e|[]|[]) ¥ (uv | px) for some p,, and let v be either integer or 


boolean value. Then, by Lemma 7, we derive (se! | [ly O?T° 4 ?]) Ysq(v" | 
p.) where v & (v’ | p.) and v’ = pi,(l,). Since v is of primitive type we have 
that v! = v. From (se! | [, 6277" + 7]) dsq(v’ | o,) and the evaluation rule 
(Szq) and (Loc) of Fig. 8 we get (se’; 1: | [kL O21" 4 7]) Usq(v | of). Finally, 
from evaluation rule (Biockx) we have that ({ se; z} | []) e(u | 4). 

On the other side, let ({ se; z}|[]) \er(v’ | e). From the evaluation rules 
of Fig. 8 we have that (se’; 1, | [l, O?T° + 7]) Usq(v" | p,). Therefore (se! | 
[l, ?T" 1 2]) Usq(v’ | p,). By Lemma 8 we derive that (e | [] |})(u | ps), 
and Lemma 7 implies v’ = v. 

Let (e|[] | []) 4 (E(v) | p+) for some p, and v. Then, by Lemma 7, 
we derive (se! | [l, O21" 1 2]) Usq (E(u) | o,). From rule (Prseq) of 
Fig. 9 and a similar propagation rule of exceptions for blocks we have 
({ se; 2} | [])[] Yo(E(v’) | 92). 

On the other side, let ({ se; z } | [{]) Wye(E(v’) | o.). From the evaluation rules 
of Fig. 9 we have that (se’; 1, | [, H?T” 4 ?]) Usq(E(v’) | p/.). From rule 
(Prsnq) of Fig. 9 we have that either (se! | [lz O?T” 1 2]) Usq(E(v’) | p4,), or 
(se! | [le 27" + 7) Weglo” | 04) and (kz | [le O?E" 4 7]) Yog(E(v’) | 4). 
However, it cannot be the case that (I, | [l, O?T° > ?]) sg (E(v’) | 04). 
So (se | [L 27" 1% 7]) Weg (E(v’) | o,). By Lemma 8, we have that 
(e | [] | []) 4 (E(v) | p«) for some v and p,. This proves the result. 


5 Implementation 


The compiler was implemented in F#. The implementation relies on the 
-NET reflective features and the F# code quotations. These allow one to 
reason about the source code and through transformation processes gene- 
rate target language code. Following is a brief description of the compiler 
implementation. The aim of this section is to provide a general idea of 
the compiler’s architecture, data structures, and the implemented compiler 
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phases needed to transform F# code into target language code. 


5.1 Data Structures 


The IL grammar is defined in terms of discriminated unions that describe 
the main IL syntactic categories such as statements and expressions. This is 
a traditional approach adopted by most functional implementations, e.g., see 
[4]. This data structure allows us to represent input programs as traditional 
abstract syntax trees that can be naturally traversed and manipulated in 
any functional language. 


5.2 Architecture and Translation 


COMPILER 


F# IL > target /_ 
source file compiler 


F# 
source file 


Figure 10: Compiler architecture 


The compiler’s architecture is shown in Fig. 10. The translation process 
is divided into two phases. First, the F# — IL component translates the 
F# source code into its IL representation. Then, the IL > target language 
compiler translates the IL to the chosen target language. The translation 
is internally delegated to the target-specific driver. The compiler currently 
supports translation to JavaScript, however, a previous proof-of-concept 
implementation supported also Python. A driver is an implementation of an 
F# interface defining methods that take an IL tree as input and return the 
target language code. During the translation process, the IL tree is visited 
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and at each tree node a specific translation method, defined in a driver, is 
executed. 

The IL tree is generated from the AST representing the F# source code. 
This latter is obtained with the Quotations library that allows a programmer 
to mark F# code that should be ignored by the compiler and whose AST 
should be returned. This way, lexical and semantic analysis are done for 
us by the Quotation library. Fig. 11 shows an example of Quotations in 
action. The constant ast is bound to the tree representation of the quoted 
expression. In other words, instead of evaluating the code between <@@ @@>, 
the compiler returns an abstract syntax tree of the enclosed expression. The 
core F# library provides the ReflectedDefinitionAttribute (RefDefAtt 
for short) which can be used to annotate functions, methods or, in F# 3.x, 
modules, to obtain the relative AST representation. 


> open Microsoft.FSharp.Quotations 


> let ast = <@@ let add x y = x + y in add 2 3 @@> 


val ast : Expr<int> = 
Let (add, Lambda (x, Lambda (y, Call(None, op_Addition, [x, y]))), 
Application (Application (add, Value (2)), Value (3))) 


Figure 11: Example of F# quotations 


To obtain the AST of all functions or methods annotated with RefDefAtt 
we proceed as follows: 


1. at runtime, we compile the desired modules to obtain a compiled 
assembly; 


2. by using the .NET reflection, we extract from the compiled assembly 
all types and definitions; 


3. we filter out definitions that are not annotated with RefDefAtt; 


4. for each function/method annotated with RefDefAtt, we take the 
relative AST. 


Once we obtain the F# ASTs, we use pattern matching to recursively 
traverse the trees and gradually build the corresponding IL tree. The 
Quotation library provides us with a rich set of active patterns for working 
with F# ASTs. 
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5.3 Extensions 


We have developed several extensions and are currently experimenting with 
several new ones: 


JavaScript DOM and project template. We developed a DOM ma- 
nipulation library with a simple DSL for generating web pages. The DSL 
allows us to build web pages in a type-safe manner. Also, we implemented 
a small F# library that makes developing JavaScript applications easier. 
Thanks to this library, when the user launches a JavaScript application, the 
generated JavaScript code is put ina .js file that is loaded into a . html 
file, that in turn is served to the user through a browser by a small HTTP 
server that is automatically launched by the project. 


Native and target code mix-ins. We are studying and have already 
partially implemented constructs for mixing in a type-safe manner native 
F# and target language code. This technique would let a developer reuse 
existing JavaScript code in a type-safe manner. 


New language drivers. We emphasize that driver extensions are really 
easy to implement. Also, target language drivers can freely use target 
language libraries. For example, one could generate target language code 
that uses 7Query instead of plain JavaScript. Such a driver could inherit 
all the code from the original JavaScript driver and then just override the 
methods that should generate jQuery code. 


Debugging. We are studying a debugging system that, when an error 
occurs in a target language, would correctly indicate the origin of errors in 
the origin language code. 


Client-Server code. Also, following the example of [20], it would be 
useful to allow a programmer to separate client- and server-side code in a 
type-safe manner. This extension is in a very early stage. 


Source languages. Many other extensions are possible. The IL in itself 
is not strongly linked to the source language, so one could implement a 
compiler which translates from a different source language. 

The project can be downloaded at: 


https://app.assembla.com/spaces/ironcat 
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6 Comparisons with Other Work 


The compilation process of high-order functional languages is often prece- 
ded by continuation-passing style (CPS) transformations to generate an 
intermediate representation of the source program, [3]. The intermediate 
form, originally expressed in the source functional language, was designed to 
allow code optimization. More specialized intermediate languages, such as 
the A-normal forms, [9], first-order intermediate languages, [10], and CPS 
languages, [17], were introduced to reduce the size of the intermediate repre- 
sentation of the code, and perform better optimizations. Our intermediate 
language is designed to be close to the target of our compilation, which is 
scripting languages such as JavaScript and Python. Our translation is remi- 
niscent of the compilation with continuation (CPS), in that it produces not 
only the TL code but also a variable which holds the value of the translated 
expression. 

Compiler correctness has been studied extensively, see [7]. In [5], a 
logical relation is defined between a simply-typed functional language with 
recursion and low-level code of a SECD machine. The logical relation 
connects the denotational semantics of the source language with a small-step 
operational semantics of the SECD machine. We also use a logical relation, 
but we define it directly between the big-step semantics of the two languages. 
In [18] a mechanically verified implementation of ML in low-level code is 
presented. An intermediate functional language is introduced, to simplify 
the translation. The proof of correctness uses, as in our case a big-step 
operational semantics. The only work to our knowledge that proves the 
correctness of a translation between a statically typed functional language 
with imperative features and a scripting language (in this case JavaScript) 
s [11]. In [11] the proof of correctness is done by embedding the JavaScript 
translation in the functional language and showing that the semantics is 
preserved. Our proof instead is direct; we define a translation relation 
between F# and IL values and configuration and prove the correctness of 
the translation. That is, the evaluation of an F# configuration converge to a 
value if and only if the evaluation of the IL configuration which is in the 
relation translation with it converges to a related value. The soundness of the 
F# type system w.r.t. the operational semantics is essential in order to prove 
the correctness of the translation. The use of big-step semantics, for both 
languages, facilitates the already quite complex proof of equivalence, however, 
it introduced the need to characterize also non terminating computations, 
and prove that a well-typed F# expression either converges to a value or 
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diverges. 

Projects similar to ours exist and are based on similar translation 
techniques, although as far as we know, we are the first to introduce an 
intermediate language in order to translate to different target languages. Pit, 
see [8], and FunScript, see [6], are open source F# to JavaScript compilers. 
They support only translation to JavaScript. FunScript has support for 
integration with JavaScript code. Websharper, see [16], is a professional web 
and mobile development framework, also available under an open source 
license. It is a very rich framework offering extensions for ExtJs, jQuery, 
Google Maps, WebGL and many more. Again it supports only JavaScript. F# 
Web Tools is an open source tool whose main objective is not the translation 
to JavaScript, but rather to solve the difficulties of web programming: “the 
heterogeneous nature of execution, the discontinuity between client and 
server parts of execution and the lack of type-checked execution on the client 
side”, see [20]. It does so by using meta-programming and monadic syntax. 
One of it features is translation to JavaScript. Finally, a translation between 
Ocaml byte code and JavaScript is provided by Ocsigen, and described in 
[22]. 

In our previous work, [12, 14], we defined a translation of the same 
source language to an intermediate language containing a construct for 
wrapping and executing code outside its definition environment. The current 
translation, and the proof of correctness, are simpler. 


7 Conclusions and Future Work 


In this paper we proved that the translation of a significant fragment of F# 
to an intermediate language close to scripting languages such as Python and 
JavaScript is correct, in the sense that it preserves the dynamic semantics 
of the language. A richer version of the intermediate language, IL, and a 
preliminary version of the translation were presented at ICSOFT 20138, see 
[12] and [14]. We have a prototype implementation of the compiler that 
can be found at the project site [13]. The compiler is implemented in F# 
and is based on two metaprogramming features offered by the .net platform: 
quotations and reflection. Our future work will be on the practical side to 
use the intermediate language to integrate F# code and JavaScript or Python 
native code. (Some of the features of IL, such as dynamic type checking, 
which are not present in the current paper, as they were not relevant for 
the proof of correctness, were originally introduced for this purpose.) The 
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current implementation also supports features such as namespaces, classes, 
pattern matching, discriminated unions, etc., some of which have poor or 
no support at all in JavaScript or Python. On the theoretical side, we are 
planning to do the proofs of correctness of the translations from IL to Python 
and JavaScript. For this, we need to formalize Python and JavaScript. (We 
anticipate that these proofs will be easier than the one from F# to IL.) 
Moreover, we want to formalize the integration of native code, and in general 
meta-programming along the lines of work by the authors, see [1] and [2]. 
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Proof of Subject Reduction for F# 


In this appendix we prove the Subject Reduction lemmas. 
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Lemma 9 /f T[y:T’!] | “tb e: T, 1 ¢ dom(d), and — u:T"’, then T | 
NE Pel ol ed. 


Proof By structural induction on e. 


Lemma 10 (Inversion) 1. Jf[ | Xt: T, then T=int. IfT| Ut 


a &~ WwW es 


10. 


Ld: 


12. 
13. 
i. 


tr,fls: T, then T = bool. 


pdf | eel thee? fer. 
cap | Sires inher 21 
dif | Se epee? 15 then f= int, and T |e F-& ant. (1 <7 & 2). 


. If | Xt if e then e; else eg: T, thenI’ | & + e: bool, and 


Pr eet <4 <2). 


. fT | St fun 2:T;>e: T, then for some T2,T1, andT2 we have that 


(a) T= Ti = T», T=T,(Po], 
(b) T2[a:Ti] | e: To, and 
(c) Vy,T y:T! €To. 


. fT |r eg eg: T, thenT| Ste: T’ > T for some T’, and 


The: 7”. 


. fT |b e,e: T, thenT| Xt e: T’ for some T’, andl | UF e: 


L, 


Ld EF | oe EP let: ere anes, s Te, then P| SE ep 207 .and 


Pla: 7,) | SF és: 7: 


If{| Xt let mutable y:Ty=e, in eg: T, thenT | Ut a: Ti, and 
Tly:Ti!] | 2 eg: T. 


FY |X let rec w:T=F ine: T, then Tlw:T] | Ut FB: FG 
(l<j<n), andI[w:T]|Xte: Tf. 


fT |S i<e:T, thenT | Ut e: T, and X()) = T. 


ifY |= Praise.e: 1, then T:|X be: Te: 


fl’ | S try 2. with 2 See? T> then T | EF epee Ty-and 
DleTe) | 2 Fear F. 
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Proof By case analysis in the last rule used in the type derivation of 
Por est, 


Proof of Lemma 1 (Type Preservation): 
Let (e | 7 | p) be such that © — (e | o | p)o. From Definition 2, clause 4, we 
have that 


1. env(o)| St e: T for some T, 
2. Foo, and 
3. De ps 


Let (e|o | p) 4) (uv | p’). By induction on the derivation of {}. We only show 
the most interesting cases which are: the base cases, the rule for application, 
let recursive and mutable, assignment, and the rule for try-catch. The others 
are similar. Consider the last rule applied in the derivation. 


Rule (Var-F) In this case e=z, and (e | 0 | p) |) (lkp(a,c) | p). Let 
z:Trov’ € o, and let f; = let rec 7:T=F in F; (1 < j < n). 
If lkp(z,0) = v’, then, from 2, we have that | v':T. Otherwise 
v' = (fr,o), and v = (Fx, o[23: TO (fi, )li<icn). From — v':T we 
have that T = T;,,, and env(c)[z:T] | 0+ F, : Ty. Therefore, from 
Definition 2, clause 1(c), we derive | v:T. Note that, if T= T, > To, 
then v = (fun x:T,-e’,o’) for some e’ and o’. Moreover, from 3, we 
get UE p. 


Rule (Pr-Val-F) In this case e=n or e=tr or e=fls, and (e| a | p) |} (e | p), 
ie., v=e. From 1, and Lemma 10, clause 1, we have that if e = n, then 
T = int. Moreover, if e=tr or e=fls, then T = bool. Therefore, 
from Definition 2, clauses 1(a) and (b), we have | v:T. Note that, 
T = T, > To, and v = (fun x:T;>€e’, 0’). Moreover, from 3, we get 
yp. 


Rule (Fn-Val-F) In this case e=fun xz:T,—>e’, and (e | a | p) J) ((e,c) | p), 
i.e., v = (e,o). From 1, and Lemma 10, clause 6, we derive T = 
T; > To, env(o) = Ty [Po], Tala:T] | OF e’ : To, and y:T! ¢ T2 
for all y and T. Since in env(o) there are not y:T!, we also have 
enu(a)[z:T]|@ e’: T2. Therefore, from Definition 2, clause 1(c), we 
get — (e,o):T. Moreover, from 3, we have © F p. 
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Rule (Loc-F) In this case e=/ for some I; so (1 | a | p) 4} (uv | p) where 
v = p(l). From 1, and Lemma 10, clause 3, we have that T = X(1). 
From 3, and Definition 2, clause 3, we get — p(l):T, UE p. If Tisa 
function type, then v has the required shape. 


Rule (App-F) In this case e=e, e2 for some e; and eg. From (e | o | 

p) | (u | px) we have that (e, | o | p) J) (fun 2:T,>e, 0") | p1), 
(e2 | 7 | pi) I (ve | p2), and (e | o’[x:Ty++v2] | p2) 4 (v | px) for some 
T,. From 1, and Lemma 10, clause 7, we have that | Ut e, : T’ > T, 
T'| St e:: T’ for some T’. From 2, and 3, we derive © — (e1 | a | p)o. 
Applying the inductive hypothesis to (e1 | o | p) 4) ((fun 2: Ti > e, 0’) | 
pi) we have that — (fun 2:T;>e,0’):T’ + T, and 41 — p; for some 
wp Ds 
From [| © + eg: T’, 2, and ©; — py we derive ©; - (e2 | a | p1)o. 
Applying the inductive hypothesis to (e2 | 7 | pi) 4) (vz | p2) we have 
that — v,:T’, and U2 - pe for some Hz D 4. 
From — (fun #:T\;—>e,0’):T’ > T, and Definition 2, clause 1(c), we 
have that env(o’) | © + fun z:T;>e : T’ + T. Lemma 10, clause 
6, implies T’ = T,, and env(o’)[x:T;] | @ + e, : T. Moreover, we 
have that | o’o. From — v;:T) we have that —- o’[r:T) + vz]o, so 
Me E (ep | o’ (a: T) +> vz] | p2)o. Applying the inductive hypothesis to 
(ey | o’ (a: Ti v2] | p2) 4) (v | px) we derive - v:T, and »’ — px for 
some 7’ D Ny. This proves the result. If T is a function type, then 
the inductive hypotheses implies that v has the required shape. 


Rule (LetMut-F) In this case e=let mutable y:T’=e; in eg, and (e | a | 
p) (wv | pa) where (er | | 0) ¥ (ty | 01), (ealy = 4) Lo | arly 
wyl) U (v | pe), and ly ¢ dom(p1). 

From 1, and Lemma 10, clause 10, we have that T’ = T; andT | Nt 
e, : Ti. So, from 2 and 3 we get © —E (e; | o | p)o. Applying the 
inductive hypothesis to (e1 | o | p) J) (vy | p1) we derive — vy:T), and 
XE p1 for some 4; D &. 

From Lemma 10, clause 10, and ©; D ©, we get ['[y:T1!] | Sit e2: T. 
Since l, ¢ dom(pi), Lemma 9 implies P | 44[ly:T)] - ely = by] : 
T. Moreover ¥4[ly:Ti] - pill) vy]. Therefore, from 2, we have 
thatdy[ly:T1] & (e2[y = 4] | o| pilly > vy])>o. Applying the inductive 
hypothesis to (e2[y := 4] | o | pilly + vy]) Y (v | px) we derive that 
= v:T, and X’ — p, for some X! D Yj [l,:T’]. This proves the result. 
If T is a function type, then the inductive hypotheses implies that v 
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has the required shape. 


Rule (LetRec-F) In this case e=let rec W=F in e; and (e| a | p) 4) (v | px) 
where (e; | 0’ | p) | (vu | px) and o’ = o[w;:Tj4(f;, 7)li<j<m where 
fj = let rec o:T=F in F;. From Lemma 10, clause 11 and 2, we get 
EK o’o, and I'[w:T] | Xt e: T. Therefore, from 3, © —& (e | a’ | p)o. 
Applying the inductive hypothesis to (e; | 0’ | p) |) (vu | px), we have 
that — v:T and 1’ — p, for some ©’ D ®. If T is a function type, 


then the inductive hypotheses implies that v has the required shape. 


Rule (Ass-F) In this case e=l<-e,, and (e| a | p) 4) (v | px) where (e | a | 
p) 4 (v | pr), and px = pill v]. 
From 1, and Lemma 10, clause 12, we have that P| © + e : T. 
Therefore, from 2 and 3 we derive © — (e1 | 0 | p)o. Applying the 
inductive hypothesis to (e; | 7 | p) 4) (v | p1) we have that — v:7, and 
1 & pi for some 4} D &. 
Lemma 10, clause 12, implies U(J) = T, and 44(/) = T. From — v:T 
we get 41 — pill vl. 
If T is a function type, then the inductive hypotheses implies that v 
has the required shape. 


Rule (Cthval-F) In this case e=try e; with x > e2, and (e | 0 | p) 4) (vu | pi) 
where (e; | 0 | p) } (v | pi). From 1, and Lemma 10, clause 14, we have 
that [| + e; : T. Therefore, from 2 and 3 we derive © — (ei | a | p)o. 
Applying the inductive hypothesis to (e; | 7 | p) 4) (vu | p1) we have 
that — v:T, and 41 — pi for some 4) D &. 
If T is a function type, then the inductive hypotheses implies that v 
has the required shape. 


Rule (CthExc-F) In this case e=try e; with x > eg and (e | 0 | p) 4) (u | po) 
where (e1 | 7 | p) } (E(u) | p1), and (e2 | ol: Te] | pi) 4 (v | 2). 
From 1, and Lemma 10, clause 14, we have that [| “+ e; : T and 
T|a:Te] | 2+ eg : T. Therefore, from 2 and 3 we derive © F (e; | 
oa | p)>. From Lemma 2 we have that - ™:7Te, and ©; — py for 
some 4; D &. From 2, and — 4:Te we derive — o[#: TE ,]>. From 
T[ae:Te] | & F eg : T, and }y D ¥ we have ['[z:Tg] | Hi - eg: T. 
Therefore, applying the induction hypothesis to (e2 | oz: Te u] | 
pi) 4) (uv | p2) we derive that — v:T, and X2 — pe for some Ng D Yj. 
If T is a function type, then the inductive hypotheses implies that v 
has the required shape. 
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Proof of Lemma 2 (Type Preservation for Exceptions): 
Let (e | o | p) be such that © — (e | 7 | p)o. From Definition 2, clause 4, we 
get that 


1. env(c)| St e: T for some T, 
2. Foo, and 
Eien wer 


Let (e | a | p) 4} (v | p’). By induction on the derivation of {}. Consider the 
last rule applied in the derivation. 

If the rule is (Turow-F), then e=raise e; and (raise e; | a | p) |) (E(v) | p’) 
where (e1 | a | p) 4) (v | p’). From 1, and Lemma 10, clause 13, we have that 
['| St e, : Te. Therefore, from 2 and 3 we derive © E (e; | 0 | p)o. Lemma 
1 applied to (e1 | a | p) | (v | p1) implies that | v:Te, and b’ — p’ for some 
bee 3s 

All other cases derive by induction hypothesis as for the proof of Lemma 1, 
by noticing that env(c) | St raise e’: T for all T. 


B_ Proof of Consistency of Semantics and Progress 
for F# 


In this appendix we prove the Consistency and Progress lemmas. Since 
we give a coinductive interpretation to the rules of Fig. 5, the proof of the 
Progress lemma use coinduction. 


Proof of Lemma 3 (Consistency): 
Consider a configuration (e | 7 | p). By structural induction on e. For the 
cases e=n, e=tr, e=fls, e=fun 7:T;—>e1, e = x, and e =! we have that 
only rules of Fig. 3 are applicable. 
For the structured expressions we only show the proof for application. The 
others are similar and simpler. 

Let e=e; e€2 for some e;, eg. Assume that (e | o | p)1}, and rule (App-F) 
of Fig. 3 was applied. Then 


1. (e, | o | p) 4 (fun 2: T’> ey, 0’) | pr), 
2. (e2| 0 | p1) 4 (ue | p2), and 


3. (e | o![a: Ty > ve] | pa) de (0 | pad: 
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By inductive hypothesis 
a. neither (e; | 0 | p) 4) (E(ve) | pe) nor (e1 | o | p)tt 
b. neither (e | o | 91) 4) (E(ve) | pe) nor (e2 | o | p1)ft, and 


c. neither (e | o’[x:T, > ve] | p2) 4) (E(ve) | pe) nor (ey | o/[a: Ty > vz] | 


p2) th 


Therefore, neither rule (PrApp) of Fig. 4 nor rule (App-tt) of Fig. 5 are applica- 
ble. 
If (e | o | p)4} and rule (PrApr) of Fig. 4 was applied, then either 


i. (e1| 7 | p) ¥ (E(v) | p’) or 
ii. (er | o | p) (fun 2:T>e,0’) | p1) and (e2 | a | pi) 4 (E(v) | p’) or 
iii. ( 
( 


e. | o | p) 4} ((fun a: T>e,0') | pi), (e2|o | pr) 4 (v | 2), and 
e|a'[ar-+0] | p2) H(E(v) |p’). 


By inductive hypothesis, if either one of i., ii. and .iii holds, then neither 
rule (App-F) of Fig. 3 nor rule (App-t) of Fig. 5 is applicable. 


Proof of Lemma 4 (Progress): 
From © — (e| a | p)* we have 


1. env(o)| St e: T for some T, 
2. Foo, and 
By 2s Ep: 


The proof is by coinduction, and case analysis over e. 

For the cases e=n, e=tr, e=fls, e=fun 1:7; e,, e =z, ande=/ 
we have that (e| a | p) |) (v | p) for some v. 
For the structured expressions we only show the proof for application and 
let mutable. The others are similar and simpler. 

Let e=e; eg for some e;, e2. From 1 and rule (TyApp) we have env(o) | 
ut ey: T’ > T, and env(c) | Ut e2: T’ for some T’. 
By excluded middle, either (e; | a | p){) or not. 
In the latter case the judgment (e | o | p) 7} follows from rule (App-7) of Fig. 5 
and the coinductive hypothesis (e; | 0 | p){}, using the first disjunct of the 
premises. 
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Assume that (e; | 0 | p)d}. If (e1 | o | p) | (v1 | 91), from Lemma 1, we get 
vy, = (fun 2: T’> ey, 0’) for some e, and o’, | (fun 2:T’>e,0’):T’ > T, 
and ©; — p; for some ); D X. From env(c) | =F e2: T’ we also have that 
X1 F (e2| 2 | pie. 

By excluded middle, either (e2 | a | p1) 4) (ve | p2) or not. 

In the latter case the judgment (e | o | )¢} follows from rule (App-#) of 
Fig. 5, (e1 | o | p) | (ui | p1), and the coinductive hypothesis (e2 | a | 1)‘. 
Moreover, (e | a | p) 1) (v | px) is false. 

If (eg | o | pi) 4} (vz | p2), then, from Lemma 1, we derive that | v,:T’, and 
“2 F p2 for some Hy D 44. From — (fun 2:7’ ¢e,,0’):T’ > T and rule 
(TyAss) of Fig. 2 we have envu(o’),x2:T’ | 0+ e,: T, and Eo’. Therefore, 
from | v,:T" follows that | o’[z:T’ + v,]o, so Hg & (e | o’[z:T’ 6 u,] | 
(2). 

By excluded middle, either (e | o/[z:T’ +> vz] | p2) | (v | px) or not. In 
the latter case the judgment (e | o | ~)7} follows from rule (App-t) of Fig. 5, 
(er | o | p) 4 ((fun 2:T’>e,0) | pi), (e2 | o | pi) 4 (ve | p2), and the 
coinductive hypothesis (e | o’[z:T, +4 vz] | p2)tt- Moreover, (e | a | p) |) (v | 
px) is false. 

Instead, if (e, | o/[x:T, > vz] | p2) 
((fun x:T’>ep, 0°) | pr), (e2 | | pr) 
derive (e | o | p) 4 (v | px). 

We can give a similar proof for the case in which the configuration converges 
using rule (PrApp) of Fig. 4 


(v | Px), then, from (eq | o | p) 1 
(Uz | p2) and rule (App-F) of Fig. 3 we 


4 
4 


C Proof of Lemma 7 


locations T’, 1”, T”, l:, and the F# expression e°. If (e|o |p) 4 (v | ps), 
then (se | p) Isq(v’ | p.) where 


(A 


Let (e|o| p) = (se| p') w.r.t. = 1:T, the variables Z, 7, W, z, the 
Bes 


) v= (v'| p,), and v' = p(k), 
(B) L¢ {1",T", 1} implies p'(1) = p'.(1), and 
(C) Le dom(p.) implies px(1) = (p.(1) | Px): 


Proof Let (e | a | p) © (se | p’). From Definition 6, clauses 5 and 6, we have 
that 


(a) for alli, 1<i<n, if a: Tj; € 0, then v; = (p'(i) | p’), and 
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(8) 1 € dom(p) implies p(1) = (p'(1) | p’). 


By induction on the derivation of (e | a | p) |) (v | px). We only show the 
most interesting cases which are: the base cases, the rule for application, 
let mutable, let rec, assignment, raise, and the try — with in which the 
exception is caught. The other cases are similar. Consider the last rule of 
Fig. 3 applied in the derivation. 


Rule (Var-F) In this case e=z and, from Definition 6, clause 2, for some 7 
such that x = 2; we have that zu; € o. From Definition 6, clause 
3 and Definition 4, clause 1, we have that se = def l,:=/’. Let 
(x |o| p) 4 (v | p) where lkp(x,o0) = v. Applying rule (Der) of Fig. 8 
we have that (def 1,:=1" | p') sq(o' (4) | p).) where pl, = p'[lL, + p'(1?)). 
If v = y;, 1.e., the value is not a recursively defined function, then, 
from (a) we have that v = (p/,(17), o,), and p/.(l,) = p). (i). Therefore 
(A) holds. 
If v; = (let rec w:T=F in Fy,c) for some k, then 


v = (Fy, o[2;: Tj (let rec :T=F in Fj,0)|1<j<m). 


Since, from (a), we have that % = (p'(17), p’), then, from Lemma 6 
we also have that v © (p’(l), 4), and p/,(l) = p/. (7). Therefore (A) 
holds. 

Since p, = p and | € dom(p’) — {l,} implies p’(1) = p/,(1), then clauses 
(B) and (C) hold. 


Rule (Fn-Val-F) In this case e=fun 1:Te’, and (e|a| p) |) (fun 2:TSe’,c) | 
p). From Definition 6, clause 2, e° is such that env(o),y:T’! | 0+ e°: 
T for some T. From rule (TyAss) of Fig. 2 we have that no y € {7} 
can be free in e°, so e° = e. From Definition 4, clause 2, we get 

e°] {#19} —( def z:—fun r—>{se°},z), where se° is such that 

[e’]{* 7} 17} =( se°, 2’) for some 2’. From Definition 6, clause 3, we have 
that se=def l,:—fun r>{se'} where se! = se°[Z := I]. Applying rule 
(Der) of Fig. 8 we derive (def /,:=fun r—>{se’} | p’) sq(fun z>{se’} | 
p’.) where p!, = p'[l, fun r>{se’}]. 

Consider the value (fun z:T+>e’,c), the configuration (fun z—>{se’} | 
p.), and the sequence of locations I”. Since z ¢ {Z} we have that 
fun r—>{se'} = (fun c>{se°})[z :=T']. From (a) and the fact that 
p, (4?) = p'(i) (1 < i < n) we derive that: for all i, 1 <i <n, 
4: Tj; € o implies v; = (p/,(U") | p’). Therefore (fun 2:T>e’,o) = 
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(fun x>{se'} | p’,), and p/.(l,) = fun x>{se'}. So (A) holds. 
Since p, = p and | € dom(p’) — {l,} implies p’(1) = /,(1), then clauses 
(B) and (C) hold. 


Rule (Loc-F) In this case e=I for some I. From env(c),¥:T’! | 0+ e°: T 
we derive that e° may not contain locations. Therefore, for some 7, we 
have that e° = yj, e = 17, and (e | a | p) 4 (p(U?) | p). From Definition 
6, clause 3, and Definition 4, clause 1, we have that se = def Lisl. 
Applying rule (Der) of Fig. 8, with rule (Loc) on the premise, we derive 
(se | p") Uae! (U2) | pi) where pl, = pill + p/(I!)]. From (8) we get 
p(l?) = (p'(U7), p’), and p(1;) = (o4.(1/), p.). Therefore, (A) holds. 
Since px = p and | € dom(p’) — {l,} implies p’(1) = p/.(1), then clauses 
(B) and (C) hold. 


Rule (App-F) In this case e=e, e2 for some ei, e2, and (e1 e2 | a | p) | 
(v | px) where (e; | o | p) 4) ((fun 2:Ti>e,0°) | pi), (e2 | o | pi) 
(Ux | p2), and (e% | o’[z: Ti+ uz] | p2) 4 (v | px). Since e = e°[y := I" 
we have that e°=e? ej, where e; = e?[y := ] (1 <i < 2). From 
Definition 4, clause 4, we derive [e°]{"}(9} = (se°,z), where se° = 
se$; se§;def z:=2 2, [ec ]{* {9} = (se, 3) (1 <i < 2), andzisa 


fresh variable. From Definition 6, clause 3, we have that se is 
sei; seg; def l,:=(l,, l,) 


where se; = seS(z7w x4 := TP PT" 1,], and {1 ,0T", 1} C dom(p’). 
Moreover def (se°) = def (se{) U def (se3)U{z}, def (se{)Ndef(se3) = 0, 
and {w'} = def (se?) — {z}. 

Consider the configurations (e; | a | p), and (se, | p’). Since e; is 
subterm of e, from © E (e|a| p)o we get © E (e1 | o | p)o. Similarly 
(se | p’) is well-formed. From the previous considerations, (a), and 
(8) we can see that clauses 2 +6 of Definition 6 hold. Therefore we get 


(er | o | p) © (sex | p’) 


w.r.t. = U:T, the variables z, y, w!, ~, the locations 1”, 1”, 1", 
l,,, and the F# expression e?. Applying the inductive hypothesis to 
(ey |o | p) } (fun 2:T>e, 0’) | p1) we get 


(ser | p) Lsqv" | p1). (3) 


Moreover, the following hold: 
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(Ai) (fun 2:7; >, 0’) = (v" | p{) and v” = pi (b,), 
(Bi) 1 {",T", 1, } implies p'(1) = p{ (1), and 
(Ci) l€ dom(p1) implies pi(1) = (p(2) | p41). 
From Lemma 1, and Definition 2(c) we have that 
(D;) no location | may occur in ej. 


Consider the configurations (e2 | o | p1), and (sez | p,). We want to 
show that these configurations satisfy the conditions of Definition 6. 
From Lemma 1 we have that ©; — pi for some ©; D %. From 
clauses 2 and 3 of Definition 6, and typing rule (TyApp) of Fig. 2 we 
get env(c) | 1:7" + e : T, for some T;. Since 17:7” C Dy and 
-E= a we derive 4; F (e2| 0 | p1)%. From Theorem 2 we have that 
(v” | p,) is well-formed. From Loc(se2) C dom(p’) C dom(p',) we get 
that (seg | p) is well-formed. Therefore AG |o| p) = (se | p’), clauses 
2 +4 of Definition 6 hold with Z, 7, U2, ~, [’, 1, 1”, los amd 65 - 
From (B;), for all 1 € {7°} we have that p’(1) = p/(1). So, from (a) we 
have that: 


a’) for alli, 1<i<n, if nou, €o, then vu; = (p4 (1), p' 
1 1 


Theor from (C1) we derive (e2 | o | p1) © (see | p)) w.r.t. 4, F, 


Y, W, 2, ie ie ie , l,, and es. Applying the inductive hypothesis to 
(e2| | pr) 4 (ux | p2) we get 


(se2 | pi) Ysq(v% | 2) (4) 


where 
(Az) ve = (vy; | Pp) and v,, = po(lep), 
(Bo) 1¢ {V,T,1.,} implies pi (I) = p)(2), and 
(C2) l€ dom(p2) implies p2(1) = (5(I) | 5). 
Let Z = dom(o’), from (Aj), and Definition 5 we have that 
vo” = (fun c>{se3[2" = I” }}) where ify C dom(p'), 
[ep] Como Utz} {9} — ( se§, 2’) for some ¥, 2’, and 


for alli, 1 <i<n’, if af: Tiou! co’, then u! & (pi (I) | p4). 


(P2 


) 
) 
(P3) 
( 


From (Bz), and (P3) we derive 


A Provably Correct Compilation of Functional 
Languages into Scripting Languages 69 


(P)) for alli, 1<i< rn’, if af:Tlou! eo’, then ul & (p4 (I?) | ph). 


Now consider the configurations (e | o’[a:T, > v,] | p2), and (se’ | p%) 
where py = p[lr > oT + 2,4. 32] and se’ = seS[z’ aw 2! := 
fig ke fhe Ly] with {w’} = def(se$) — {z’}. We want to show that these 
configurations satisfy the conditions of Definition 6. 

From Lemma 1 we have that — (fun 2:T,>e,0'):T; ~ T. From 
Definition 2(c), and rule (TyAss) preceding Definition 2 we derive 
that env(o’)[z:Ti] | 0+ e : T, and | o's. Applying Lemma 1 to 
(eg | o | pi) VY (ue | pe) we have — wv,:T), and “2 — pe for some 
“2 D by. Therefore, we get — o’[r:T; 1 vz]o, and Ne — (e | 
ox: T, + vz] | p2)0. 

From (3), and Theorem 2, we derive that (v” | p) is well-formed. 
From (P,), (P2), and definition of se’ we have that FV(se’) = 0, and 
Loc(se’) C dom(p$). From (4), and Theorem 2 we have that p/ is 
location closed. Therefore, (se’ | p3) is well-formed. 

From (P2), (C2), and definitions of se’ and pj we can derive that 
(ep | o’[u: Ty + vz] | p2) & (se’ | p) w.r.t. Hg, the sequences of disjoint 
variables 7’ x, ™’, z’, the sequences of disjoint locations ee ie Ls 
and the F# expression ep. 

Applying the induction hypothesis to (e | o’[a:T’ vz] | p2) 4 (v | px) 
we get 


(sel | ps) Ysq(v’ | pL) 
where 
(As) v & (v! | pl!) and v! = pl(L), 
(Bs) 1¢ {1°,T”, 1} implies p(1) = p"(1), 
(C3) 1 € dom(p.) implies p,(2) ~ (p!(2) | 4). 


Applying rule (Biocx) of Fig. 8 we derive ({se3[z’ := Tigi | phlle > 

v}]) der(v’ | off). Consider the evaluation of the configuration (def l,:=(l,, lL.) | 
py). From (Aj), and (Bg) we derive p4(I,) = fun e>{se8[z’ := 1" J}, 

and from (Ag) we get p5(l,.) = uj, Therefore, applying rule (Apr) of 

Fig. 8, we derive that ((l, lL.) | pb) Vex(v’ | po’). By applying (Der) we 

have 


(def Le=(l, les) | 05) Uselv! | plllle = v')). (5) 
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Let p!, = pel, := v']. From (3), (4), and (5), applying rule (Sq) twice 
we get 

(se1; 8€2; def l,:=(L, len) | 9") Yst(v" | 4). 
From (A3), and definition of p’, we have 


(A) uv = (v'| 9.) and vo! = p(t). 


From 2°}. 5. 4". bob tT” Gen dome) = We (By), and 
(Bz) we derive that 


(BY) 1¢ {T,T°,1,} implies p(0) = o,(0). 
Finally, from (C3), and the fact that l, ¢ dom(p,), we get that 
(C’) 1€ dom(p,) implies p.(1) = (eo, (2) | p.)- 


This concludes the proof. 


Rule (Let-Mut-F) In this case e=let mutable y:T=e, in eg. Assume that 


y ¢ {z,y}, (let mutable y:T’=e; in eg | o | p) I (vu | px) where 
(er | o | p) UL (vy | pr), and (ealy = by) | | prlly > ey]) 4 (v | pe) for 
ly Zdom(pi). 

Since e = e°[y := T°], then e°=let mutable y:T=e? in e§ where 
e; = e°/y := 1"). From Definition 4, clause 8(a), [e°]7}47} = ( se°, 2 ) 
where se° = se9;def y:=z1; se§, and [e°]{7}t9 = (se9, %) (1 <i <2). 
From Definition 6, clause 3, we have that se is se};def ly:=l,,; seo 
where se; = se8[ryw y= TTT" 1], and {0,071} C dom(p’). 
Moreover, def(se°) = def(se{) U def (se$), def(se{) M def(seS) = 0, 
and {w’} = def (se?) — {x}. 


As for the proof of the case of application we can prove that 


(er | o | p) © (ser | p’) 
w.r.t. © = 1:T, the variables Z, 7, w!, %, the locations 1”, 1”, 1", 
l.,, and the F# expression ef. Applying the inductive hypothesis to 


(e1|o | p) 4 (vy | pi) we get 
(ser |p") Vsq(vy | 71). (6) 
Moreover, the following hold: 


(Ai) vy = (uy | pi) and vy = p(t.) 
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(Bi) Lg {0',0", 1} implies p'(1) = pi,(), and 
(Ci) l€ dom(p1) implies pi (1) = (p(2) | 4). 


From rule (Der) of Fig. 8 we have 


(def ly:=ly | pi) Ysq(vy | Pilly = r%yI)- (7) 


Consider the configurations (e2[y := ly] | o | pilly > vy]), and (see | 
Pilly == vf). 

From © E (e1 | o | p)o and Lemma 1 we have that: 5’ & p; (for some 
¥’ DD), Koo, and k w:T" (since env(c) | :T" + a : T’). 

Let 5; = ¥',ly:T, then D1 & pi[l, 0 vy], and env(c) | 1:7", 4:7 + 
e2: T. Therefore 41 — (e2[y := 4] | o | pilly + vy])°. 

From Theorem 2 we have that (v, | p) is well-formed, and, since 
Loc(sez) C dom(p') C dom(p), we get that (se2 | pi [ly = vy]) is 
well-formed. 

From (e|o | p) © (se | p’) we derive that clauses 2 + 4 of Definition 6 
hold for the conapyravons ae = Jul Ie o | sy > vy) and (seg | 
Puen AD) with Z, Jy, w, 2, 0,0 ly, 1°, L,, and e3. Therefore 


(ealy = 4) | o | pill) > vy) © (ser | Pilly = vy))- 


Applying the inductive hypothesis to (e2[y := ly] | a | pill)  vy]) 4 
(uv | px) we get 
(sea | pully = v']) Vsa(v" | 4) (8) 


where 
(Az) uv = (v'| pL) and vo! = p, (Ly), 
(Bo) 1¢ {V,T,1.,} implies (p; [ly = vf])(1) = o(1), and 
(C2) 1 € dom(p,) implies p,(1) = (o.(1) | p)- 

From {7°} D {7,7 L,,k,,}, (B1), and (Bz) we derive that 
(B’) 1g {U,T", 1} implies p'(1) = p4(I). 

Therefore (A), (B’), and (C2) prove the result. 


Rule (LetRec-F) In this case e= ae rec W’=F in eg. From rule (LerRec-F), 
if (eo | o[w;:Tj-+(let rec PHP an.F yo), | py ie | prs 
then e |} ‘ip | p1). pene that {mw} {7,9} = 0. From Y —& 
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(e | o | p)*, and typing rules (TyRec) and (TyAss) of Fig. 2 we 
have that for all j, 1 < 7 < m, FV(F;)9 {gy} = 0. From Defini- 


tion 6, since e = e°/¥ := = 7" ], we derive e°=let rec W=F in ef 
where e9 = e9[9 := ), eth = tinea Tee (lr ang Som): 
From Definition 4, clause 9(a), [e°]{7!9} = (se°, 2). So se° is 
seq: +: 5 ser; def ae --+ ;def wy,:=%m}; se3, where {7} = dom(o), 


(Pi) [FJ FP =( see 92), Le, seS = def 2;:=fun x>{sej} 
where [e;]{* 27} 7} = Cee, o.) (US eS Ha), 


(P2) [es }to} —( 5€5, % ), 

(P3) se = $€1;--+ } S€m; def hy =ly5+++ 3 def by, =L,,5 $€0 where 
se, = seQ(ey wm :-T PT L,] O<k<m), = Wa-:- and, 
and w° = def (seg) — {x}, 

(Pi) p! =p'+p™, dom(p™) = dom(p), and {1 ,T”, lg} C dom(p%). 


From the definition of the translation of functions (Definition 4, clause 
2) we have that for all 7, 1 < 7 < m, the only defined variable in se; is 
2, and z; cannot occur in the body of the function. Therefore, from (P3) 


we have se; = def l,,:=F; where fF) = fun r>{se5[TW! := can 
(L<9 <im): 
Applying rules (Sq), and (Der) of Fig. 8 we have that 


(se1;-++ 5 S€mjdef by :=ly5+++ ;def buy s=lem | 0) Vsq(Fm | 0's) 


where ply = Phys le;  Pilicjem: 
Let vft = (let rec W:T=F in Fy,o), and o’ =o[wy: Ty 0K 1 <k<m: 
We want to show that (e | ; | p) & (seo | p’1) wart. =e, the 


variables Zw’ (dom(o’)), J, W°, zo, the locations I’ 7” , 7”, T°°, 1,,, and 
the F# expression e9. 

From © / (let rec @’=F in e9 | o | p)o we have that © - p, and 
from rule (TyRec) of Fig. 2 we get 


1. Clo?) | Se ee eS 9 Xm), ond 
2. Tfw':T)|Xb eo: T 
From 1. and rule (TyRec) we have that . | “+ let rec W':T=F in Lae 


T; (1<j<m), and / 0’. Therefore © — (€ | a’ | p)o. 
From (se | p’) well-formed and Theorem 2 we derive that (FY, | 
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PUbv' » ba, t+ Fili<j<m) and (seo | PL!» ba, t+ Fili<j<m) are well- 
formed. 

From T'fw’:T] | & + e9 : T, (P2), and (P3), and {w’} C {w}, and 
{Z} 1 {Wo} = 0 we derive clauses 2 and 3 of Definition 6. From (P) 
and {Wo} C {w} we have that p! = p! +p”, dom(p™) = dom(p), and 
{00° , ua) dom(p!). 

Let 2/:T’ 1 v" €o’. If 2':T’ 4 uv" €o, then, from (a) and p'(I,) = 
p' (ly) we have that v” & (p/(l,”) | p). If instead 2’: T’ 4 vu” ¢ o, then 
for some j, 1 <j < m, 2’ = wi, v" = (let rec w:T=F in F;,0), 
and pi (ly) = Fj. From pi (ly) = Fi, (1 < k < m), and (Pi), we 
have that (let rec W':T=F in Fj,o) & (Fi | p,). Therefore, we can 
conclude that (eg | a’ | p) © (seo | p';) w.r.t. & = I:T, the variables 
zw’ (dom(a’)), 7, W°, and z, the locations 1” rhe U1) and band 
the F# expression e9. 

Applying the inductive hypothesis to (e9 | 0’ | p) ) (v | px) we have 
that 


(*) (seo | 1) Yealv" | pL) 


where 


(Ai) v= (v'| pl) and vo’ = py(le), 
(Bi) 1g {V,0", leo} implies p'(1) = p/,(1), and 
(C1) le dom(p.) implies p.(1) = (o.() | pL). 


From (Bi), {Wo} C {w}, and 1 ¢ ae ped implies p’(1) = p/(1), we 
derive that 


(Bi) 1g {UT Lo} implies (1) = pl.(1). 
Therefore (Aj), (Bi), and (C) prove the result. 


Rule (Ass-F) In this case e=/<-e, and (i<-e; | a | p) |) (v | px) where 
(ey |o| p) 4 (v | pr), and py = pill v]. Since e = e°[y := TJ, then 
e°=y<-e®? where y € {7}, and e = eo[y := 1"). 

From Definition 4, clause 10, we have that [e°]{!}( = ( se9;7<z, z) 
where [eg] {7} a} = (se{,z). From Definition 6, clause 3, we derive 
that se is sej;l,<l, where sey = se{[zywz := PUT Ll), {a} = 
def (se9) — {I,}, and {1° ,1°T", 1} C dom(p’). Therefore (e; | o | p) © 
(sez | p’) w.r.t.  =1:T, the variables 7, 7, W, z, the locations ee 


l, l,, and the F# expression e?. 
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Applying the inductive hypothesis to (e; | a | p) |) (vu | pi) we get 
(se1 | p’) Uso(2" | 0) where 
(Ai) v = (v'| pj) and vo’ = pi(L), 
(Bi) 1¢ {I",T", 1} implies p’(1) = pi (I), and 
(Ci) 1 € dom(p1) implies p.(1) = (p(2) | p')- 
( 


From (sez | p’) dsq(v’ |p), applying rule (Seq) and (Ass), we get 


(se1; ly<kz | p') Yeq(v" | 04) 


where p!, = p{ [ly > v’]. 
From (A;) and the definition of p/, we get 


(Aj) v= (v'| p,), and v' = pi.(t). 


Since pi, and p/, differs only for the location l, € {1}, from (B1) we 
have that 


(BY) 1g (F,7",1.} implies p/(2) = o4(). 
Finally, from (C1), px = pi{l'> v] and (A4) we have that 
(Ci) 1€ dom(p,) implies p.(1) = (o(1) | pL). 
Therefore (A‘), (Bi), and (C') prove the result. 


Rule (Throw-F) In this case e=raise e), and (e| o | p) |) (E(v) | px) where 
(er || p) 4 (v | px). 
From Definition 4, clause 11, we get that [e°]{*}t4 = ( se9; raise z,z) 
where [e°]{*}9} = (se°,z). From Definition 6, clause 3, we have 
that se is se;;raise l, a sey = seS[zyuz :=T IT i], fw} = 
def (se$) — {i}, and ue ® lL} C dom(p’). Therefore (e; | o | ey 
(sey. lio) wrt. US EF, i variables Z, J, W, z, the locations 1”, 1”, 
1”, l., and the F# expression ef. 


Applying the inductive hypothesis to (e; | a | p) |) (uv | px) we get 
(se1 |p’) Uso(2 | pt) where 

(Ai) vS(v oy and vu! = pi,(1z), 

(Bi) 1¢ {1",T", 1} implies p'(1) = p/,(), and 

(Ci) le implies p,(1) = (p,.(Z) | ph). 
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From (se; | p’) dsq(v’ | p.), applying rule (Szq) and (Turow), we get 


(se1; raise l, | ie) {eq(v" | Px) 
Therefore (A), (B1), and (C1) prove the result. 


Rule (CthExc-F) In this case e = try e; with z > eg, and (try e; with x > e9 | 
o| p)} (v | px) where (e1 | o | p) 4} (E(vr) | p1), and (e2 | of: Terai] | 
pi) + (v | px). 
Since e = e°[y := 1"), then e°=try e? with x > e§, where e; = e°[7 := 
1’]. From Definition 4, clause 12, we have that [e?]{7}7} = (se°, z ) 
where se° = (def z:=_;try {se1;z<-z} catch(2z) {seo;z<z},z), 
and [e°]{*}9 = ( se?, %) (1 <i < 2). Moreover, since z is fresh, we 
have that z ¢ FV(se®) (1 <i < 2). 
From Definition 6, clause 3, we have that se is 


def |,:=_;try {se1;l,<l,,} catch(2) {seg; l,<-l,,} 


where se; = se8[ryw y= T UT" 1], and {0,0T", 1} C dom(p’). 
Moreover: def(se°) = def(se{) U def (se), ee A def (se5) = 0, 
{w'} = def (se?) — {x}, and l, is not in se; (1 <i < 2). 

As for the proof for application and let-mutable we can show that from 
(e|a| p) & (se | p') we derive (e; | a | p) © (se, | p') wart. DH=LT, 
the variables Z, 7, W!, 2, the locations 1”, 1”, T”’, l.,, and the F# 
expression e;. 

Applying the inductive hypothesis to (e; | a | p) 4) (E(u) | p1) we get 
(ser | p’) sq(E(vy) | p), and the following hold: 


Pi (le); 
(1) = pi (i), and 
= (o4(1) | ph): 


From rule (PrSeq) of Fig. 9 and propagation of exceptions for blocks 
we have that 


(Ai) vm = (vy | p1) and yy = 
(Bi) 1¢ {",T", 1} implies p 
(C1) 1 € dom(p1) implies pi (1) 


({sers ll} |p’) Yo(E(e) | 4). (9) 


Consider the configurations (e2 | g[a: Te] | 91) and (seo[x := l,] | 
P [be := v4). 

From © —- (e, | o | p)o and Lemma 2 we have that ’ | p; for 
some 4; DY, — oo, and — w:T¢. Therefore - oz: Ter], and 
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1 EF (ee | o[a: Te v1] | p1)0. 

From Theorem 2 we derive that configurations (E(v;) | p,) and (u} | p4) 
are well-formed. From Loc(sez) C dom(p') C dom(p',) we get that 
(seg|x := Le] | p4 [le := v{]) is well-formed. 

From (e | a | p) © (se | p’) we derive that clauses 2 + 4 of Definition 6 
hold for the configurations (e2 | o[z:Tg-v] | p1) and (se2[x := I, | 
pi [le = vi]) with T, Jy, W, 2, UM ly, 1", L,, and e§. Therefore 


(e2 | o[x: Tera] | pi) © (sea[a := be] | pille = vi). 
Applying the inductive hypothesis to (e2 | o[z: Te 11] | p1) 4) (v | px) 
we get (seo[r := L,] | p[le := vj]) Vsq(v’ | 4) where 

(Az) v= (v'| pg) and v! = p9(ho), 
(Bo) 1¢ {V,T,1.,} implies pi (I) = p5(2), and 
(C2) 1 € dom(p,) implies p,(1) = (p5() | p%)- 


Let p!, = ps[l. > p{(L,)]. From rules (Sze) and (Biocx) of Fig. 8 we 
have that 
({sea[a = la}; ele} | pi) doi(v" | 94). (10) 


From (9), (10), and rule (CruExc) of Fig. 9 we derive that 
(try {se1;.<k,} catch(2z) {seg[z := ke]; leh, } | p’) Use(v’ | 04). 


From rules (Der) and (Sra) of Fig. 8 we have that (se | p’) dse(v’ | p.). 
From (Ag), (B1), (B2), (C2), the definition of p!,, and l, ¢ dom(p.) we 
have that 

(A3) v= (v' | p,) and v' = p(t), 

(Bs) 1¢ {I",T", 1} implies p’(1) = p/,(I), and 


This concludes the proof. 
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